» tagged pages
» logout

sorted by: recent | see : popular
Content Tagged with hyperic + hq

Hyperic Announces MySQL Performance Study Results

MySQLFirst Enterprise Application to Prove MySQL Supports Immense Scale

JAVAONE?San Francisco, Calif. - News Release:

  • Today at JavaOne, Hyperic (Booth #1028), announced the results of a large scale performance study on Hyperic using Sun Microsystems? MySQL database as a backend.
  • Results showed Hyperic monitoring upwards of 2.3 million metric transactions per minute.
  • These results definitively prove that MySQL and Hyperic can be a compelling option for even the most demanding enterprise and web applications.
  • Hyperic customer CNET was part of large-scale beta testing of MySQL on Hyperic.

About the tests:

  • The tests simulated a large-scale deployment monitoring 32,000 services across 675 discreet managed platforms.
  • There were two primary tests?designed to determine the actual and maximum loads amount of metrics per minute that Hyperic is capable of running on MySQL.
    • In the Actual Load test, Hyperic HQ averaged 220,000 metrics per minute, with minimal server load for either Hyperic HQ or MySQL.
    • In the Maximum Load test, Hyperic HQ achieved a record 2.3 million metrics per minute, with constraints on the Hyperic Server and only moderate load on MySQL.
  • The test setup used standard hardware that would typically be used to run Hyperic HQ with MySQL
    • The Hyperic HQ Server ran on a 2 Quad Core, 2GHz machine with 16 GB of RAM, 4 GB of Heap and a NIC with a 1 GB interconnect between HQ and MySQL
    • The MySQL Database Server ran on a 2 Quad Core, 1596 MHz machine with 8 GB of RAM, 4.5 GB InnoDB buffer pool, 16 thread concurrency, O_DSYNC flush method, and RAID-1 146G SAS 3G HardDrives

Supporting Quotes:

“For growing web-driven companies, scaling their web applications is critical to their business. Traffic is unpredictable and can grow exponentially. Operations teams must not only monitor every component of their application stack, but quickly respond if things go wrong. These performance results prove that the combination of Hyperic and MySQL is a good fit for companies that need a massively scalable web infrastructure.? — Paul Melmon, senior vice president of engineering at Hyperic

?MySQL has been designed and optimized to handle the fast-growth and high-traffic requirements of today?s modern online applications. As Hyperic is also targeting this same Web audience, there is a natural synergy between our products. MySQL and Hyperic address enterprise-level needs for performance, scalability, availability and reliability.? –Zack Urlocker, vice president of products, Sun Microsystems Database Group

“Support for MySQL has proven to be a major win for Hyperic customers by offering a scalable, enterprise class data store with the array of features they demand to handle reliable backup, archive, and disaster recovery of the highly valuable data Hyperic HQ captures. Since the official release in late January, we’ve had about a quarter of our Enterprise customers either migrate or express interest in migrating to MySQL as a database backend.” –Marty Messer, director of customer success at Hyperic

Supporting resources:

MySQL Performance study

More about Hyperic HQMore on MySQL?s new 5.1 version

More about JavaOne

Hyperic?s History with MySQL

MySQL: Planet MySQL

Hyperic HQ 3.2 Beta Now Available

The first release of Hyperic HQ 3.2 Beta is now available for download. This exciting new release is designed to provide a more powerful ?single pane of glass? to monitor, diagnose and manage today?s complex, custom, web-based IT environments. In addition, significant infrastructure enhancements to the core Hyperic HQ platform were added to deliver the most scalable and manageable enterprise monitoring software available in open source.

New Diagnostics and Visibility
Today?s IT administrators deal with an increasing burden of disparate technologies, and changing resources to monitor and maintain. Typically, they rely on a variety of utilities and diagnostic tools to ensure and restore availability to their systems. Hyperic HQ 3.2 introduces three new capabilities that provide both new and existing users of HQ a single console to manage all layers of their infrastructure:

  • Live Exec Data ? Instantly see your most CPU intensive processes (top), disk usage, network connections and more across your entire cluster of Windows and *nix platforms in a single view!
  • Currently Down Resources ? This quick look screen gives users the ability to view all down resources and their length of down time at a glance in one page. The view can be more narrowly filtered by generic or specific resource type, and can also be sorted by resource name, type, exact down time, and length of down time.
  • Nagios Import Utility ? This new utility automatically imports Nagios hosts, commands and service object. This utility provides administrators currently using Nagios easy access to all the custom checks and configuration currently supported in their Nagios environment, while extending all the additional benefits and features of the Hyperic HQ platform to these users with the click of a button.
  • Improved Nagios Integration ? The Hyperic HQ 3.2 Nagios plugin has been extended significantly to provide Nagios administrators the ability to run Nagios plugins natively and view Nagios Services, Hosts, and Statuses in a way that is identical to the Nagios Service Details interface.

More Scalable, Manageable Infrastructure
Hyperic HQ users run some of the largest website and web applications in the world. Providing monitoring and management capablities at this scale can be a daunting task, but it doesn?t have to be. Hyperic HQ 3.2 introduces powerful infrastructure enhancements to ensure maximum visibility with minimum overhead:

  • Scalability Improvements ? Hyperic aims to provide the most scalable systems monitoring and management software available in open source with Hyperic HQ 3.2. Significant investment in powering more concurrent checks, collecting more log data, and increasing the database performance for both queries and data insertion will demonstrate immediate results for large scale enterprises. Significant benchmark testing will be conducted in parallel with this Beta, and results will be shared.
  • MySQL Database Support - Full support for MySQL database to be used as backend data store for Hyperic HQ 3.2, leveraging the proliferation of MySQL in the enterprise and existing DBA expertise. The performance of MySQL is expected to be on par with the other backend databases we currently support: Oracle, and Postgres.
  • HQ Health Check ? The Hyperic HQ Server now supports self-diagnostics on the performance of the server itself, providing users and Hyperic Support a better way to be assured their monitoring system is always available.
  • Global Alert Disable - For scheduled maintenance or planned outages, the HQ administrator can globally disable all alerts on-demand in HQ 3.2, thereby preventing unwanted alerts from being generated during these times.

This release is intended for early preview and community participation in perfecting this release. It is not recommended to replace your current HQ production environments. The GA release of Hyperic HQ 3.2 will be available later this winter and will support a direct upgrade from your current Hyperic HQ 3.x environment. For more information on the Hyperic HQ 3.2 Beta see the release notes. Download today and be sure to participate in our user forums and bug forums.

Expanded Community Rewards Program
To encourage the community even further to participate in improving the quality of both the new Hyperic HQ 3.2 Beta, as well as Hyperic HQ installations in production today, we have extended the Hyperic Community Rewards Program. The program now provides members new points awarded for identifying new bugs, fixing reported bugs and contributing new plugins or HOWTOs for the HQ platform. Various rewards are available to power users who contribute at significant levels.

MySQL: Planet MySQL

Hyperic Hint #1: Fixing Transaction ID Wraparound Failures in built-in HQDB

The built-in HQ database is PostgreSQL. Recently, users have been discovering PostgreSQL has a certain limitation: it will not execute more than 2 billion transactions between vacuums. In rare cases, an HQ built-in database can get into this state.

If this happens, the database will stop accepting connections and HQ, which needs a data store, will obviously cease to operate properly. The immediate symptom will be that users will not be able to log in to HQ and the message displayed on the screen will be The backend datasource is unavailable.

backend unavailable

That error is not enough to say for sure that the problem is PostgreSQL avoiding wraparound failure by not accepting connections. A quick look at the hqdb.log can confirm. The telltale log entries look like this:

FATAL: database is not accepting commands to avoid wraparound data loss in database "postgres"
HINT: Stop the postmaster and use a standalone backend to vacuum database "postgres".

Happily, postgres tells you how to solve the problem. It’s not very specific, though so I’ll add some details.

The first thing to do is immediately shut HQ down (including the built-in database). Next, start just the database in single-user mode. Technically, you only really need to run a VACUUM, but since we’re here, we might as well be thorough and run VACUUM FULL ANALYZE.

I’ve created a script to start the built-in HQ database in single-user mode. It’s a slightly modified version of the db-start.sh script that is included in HQ installations. It takes one argument which is the name of the database to start up. The database name to VACUUM is specified in the hqdb.log message (it is “postgres” in the message above). Start the database with the script and you will get dropped into the psql command line. Run the VACUUM and exit. Looks something like this:

$ bin/db-start-single-user-8.1.sh postgres
PostgreSQL stand-alone backend 8.1.2
backend> VACUUM FULL ANALYZE;
VACUUM
backend>

When it’s done, you send an EOF (usually control-D) to exit the shell and shut down the database. At this point, you’re done and you can start HQ normally. Things will work and will usually perform much faster.

For more information on this PostgreSQL, check their documentation on how to avoid running into it to begin with.

MySQL: Planet MySQL