This plugin boost's Cacti performance especially for Large Sites. It does this by introducing four new features to Cacti. These features are designed to reduce the I/O load generated by the sheer number of updates required to the RRDfiles. In addition it allows the CPU load to be reduced by Caching commonly viewed graphs. In addition, it allows the RRDfile updates to be handled by an update server, thus allowing the Cacti administrator to restrict web site accounts from having to grant read/write access to the RRDfiles. Lastly, it allows the RRDfiles to be updated on-demand in order to maintain the traditional behavior of Cacti.
- On Demand RRD Updates
- Timed and Mass RRD Updates by Number of Records
- RRD Update Service
- PNG Caching
Before you install Boost, you need to have met the following pre-requisites:
- Cacti 0.8.7 and above.
- Cacti Plugin Architecture v2.x
- MySQL 5.0 or above. Earlier versions may work, but have not been tested.
- Have quite a bit of system memory available to hold your memory resident database and/or your sql results during major rrd update cycles.
Before enabling boost, please consider very carefully how you plan to use it long term. Carefull thought should be given to how often you update RRD's at what point you need to either increase your MySQL max heap table size, or increase your update frequency. You should also consider carefully how much memory to allocate to PHP when retrieving records during major updates.
If you are unsure of what I am talking about, you should not use Boost!!!
Install is similar to other plugins with the following notes:
- By default, Boost installs like any other plugin. From the plugin management page, Install and Enable the plugin.
- When it installs, it installs by default as a MEMORY table. Before you fully enable the plugin, you must determine the system sizing required to use this plugin.
- Even when you Enable this plugin from the Plugin Management page, it is not fully enabled. This is done for a reason. You must calculate how many rows you will be maintaining in the boost table and how large your boost table needs to be.
To determine how many records you can hold in the boost table, you need to know the following pieces of information:
- The number of Data Source rows in your poller cache and how many you expect in the future
- The maximum size of any result stored into the poller_output table as updates occur
- Your current max_heap_table_size variable in MySQL
Once you know these two pieces of information, you can calculate how many rows will be able to maintain in the poller_output_boost table, and how you must modify poller_output_boost and poller_output tables.
Let's say, for example, that your poller cache contains 200k rows, and the maximum length of any row is 20 bytes, about the size of a 64bit counter. If you are running scripts, ones that return very long results, like the MySQL statistics plugin, you should consider carefully the next step.
In this case, we will assume that even though the largest value returned is 20 bytes, we will elect to maintain a maximum output column width of 50 bytes.
The important thing here is that memory tables store the full size of the column, even though the column type is varchar(). By default it's varchar(512). Therefore, if your system only needs 50 bytes, you will have 90% waste in your poller_output_boost table.
The next step would me to modify the structure of your poller_output and poller_output_boost tables. You would do this by doing the following:
alter table poller_output, modify column output varchar(50) not null default ””, engine=memory;
alter table poller_output_boost, modify column output varchar(50) not null default ””;
It's also important that the poller_output table is converted to memory, eliminate any disk I/O related to poller updates.
Now, you need to determine how many polling cycles will fit into your poller_output_boost table. In this case, when sizing the poller_output_boost table, you take the output column width and add 34 bytes per record. So, in this case, each data source result to be stored in the poller_output_boost table would take 84bytes.
Then, with the Maximum Heap Table size in hand, and let's say the default is 16MBytes for the largest table (the MySQL default), you can calculate the number of poller intervals that you can store without running out of MySQL memory. So, let's take our example:
200k Cache Entries x 84 Bytes Per Poller Cache Row = 1,680,000 Bytes per Poll
This means that your poller_output_boost can handle 10 Cacti polls, or roughly 4/5 of an hour of poller data before it must be cleared by the system.
As all things go, you should not want to take your system to the edge. So, it is best to increase the Maximum Heap Table size of your system.
But let's look at the problem a different way. Let's say that you wish to perform major updates every 4 hours. With a 50% memory reserve, we should plan for 6 hours of updates. This way, we need to have size for 72 poller updates in your poller_output_boost table. This means that the Maximum Heap Table must be at least 131,040,000 Bytes.
So, let's call it a deal. Provided you have enough memory, and I expect that you do, you would edit the /etc/my.cnf and add/modify the following line:
Then, save the file, and restart MySQL. Once this is done, you are ready to “enable” Boost.
You enable the Boost plugin by simply going to Settings → Boost and enabling On Demand Updates. Before you do this you must first determine if your Apache account has RW to the RRDfile's and directory and if directory permissions guarentee that the RRDfiles, created by the poller account will be writable by Apache. Once you have done this, you may move onto tracking the updates process.
Doing this, is as simple as going to the Console → System Utilities → View Boost Process Status. This screen provides an excellent diagnostic interface for Boost. You can verify what the “actual” maximum length entry in your poller_output_boost table is, as well as how many rows can actually be stored in your memory table. This should be done right away to verify that everything is working as expected.
The README file contains a very detailed discussion on installation and enabling the Boost Server if required. Seek that documentation for installation and usage guidance.
Also, if you need additional help, please goto http://forums.cacti.net
— 5.1 —
- feature: Support for ifHighSpeed
— 5.0 —
- feature: Another one deep performance tuning and code cleanup
- feature: add upstart file to start boost_server
- bug: replace some deprecated statements
- bug: cope with E_DEPRECATED
- compat: adding some more logging to cope with setuid issues
— 4.3 —
- bug: Correct misspelling
- bug: Plugin Hook Registration for Fetch on Upgrade is not enabled by default
- feature: Set the permissions on the Cache files so that they can be managed by the poller
- feature#0001853: Boost v4.2 does not check graph size before pushing cached image
— 4.2 —
- compat: Don't override Cacti log level
- bug: eliminate harmless temporary table errors
- bug: when disabled, this plugin should not run
- bug: warn if you are attempting to use boost redirect and spine isn't in use
— 4.1 —
- bug: Major issue with BTREE PRIMARY KEYS and MEMORY TABLES in MySQL causing gaps
- feature: When boost redirect is not in use, do not update to the second to prevent graph breakage
— 4.0 —
- feature: Add support for Cacti's new rrdtool segfault detection and 0.8.7f
- bug: Setting logging to MEDIUM and higher causes boost images to break
— 3.1 —
- bug: Boost poller statistics logging missing global variable declaration
- bug#0001643: When boost 3.0 plugin is installed and then uninstalled it doesn't cleans database entries properly.
- bug#0001555: Boost errors generated in log when another user has graphs open
- feature: Allow boost to recover from rrdtool crashes
- compat: Make the error handler not require PHP 5.2
- compat: Remove PIA 1.x support
— 3.0 —
- feature: Deep performance tuning and code cleanup
- feature: Add logging to boost updates for performance tuning
- feature: Add hooks to support 95th Percentile and Bandwidth Summation
— 2.6 (Unreleased) —
- bug: Initial RRDfile update taks two boost cycles and not one
- bug: Cacti RRDtool fetch command bypasses boost causing issues
- bug: Don't optimize boost table if it's in MEMORY storage engine
— 2.5 —
- feature: Integration with DSStats
- feature: Support boost redirect for large systems
- feature: Properly support structured paths
— 2.4 —
- bug: [Boost 2.3] Include line referring to thold plugin
- bug: Should be db_fetch_row and not db_fetch_cell
- feature: Allow specification of memory limits
— 2.3 —
- feature: Better max memory reporting for older PHP installs
- feature: Reduce the load on the database server when displaying boost stats
- feature: Integrate better with tholds vrule display (image caching off)
- feature: Upgrade Automatically when either viewing the console or the plugin management page.
— 2.2 —
- bug: If running the boost server, mysql can timeout causing 2006 errors
- bug: Typo relative to Linux Kernel versions in relative to command length
- bug: Logging did not work on all occasions due to an undefined variable error
- bug: Improve the counting algorythm to remove some bogus RRDtool update errors
- bug: Check the validity of Multivalue updates prior to allowing updates
- bug: Correct documentation relative to the the inittab process so that it works
- bug: Prevent more than one Boost Server from running at a time by validating Socket bind
— 2.1 —
- bug: Correcting overrun issues
- bug: Rename maximum rows to maximum data sources
- bug: RRDupdate batch process was not working as designed causing excessive memory to be consumed in some cases
- feature: Log memory performance and make available via UI
— 2.0 —
- bug: remove the base start time, it complicates things
- bug: make version, force, and debug options consistent
- bug: rrdupdates oftentimes caused gaps in graphs due to limit issues
- feature: add an rrdtool output logging option
- feature: support inittab for restarting the boost server
- feature: support process locking control methodology
— 1.8 —
- bug: correct issue with multiple temporary tables using the same name are encountered
- bug: significant bug from 1.6 that prevents the poller_output_boost table from emptying completely
— 1.7 —
- feature: Add Cacti 0.8.7 compatibility
— 1.6 —
- feature: make the delete process a high performance one by batching the deletes
- bug: set a good memory limit and runtime in poller_boost.php
— 1.5 —
- bug: Under some circumstanced the poller_boost.php could not be fored to run
- bug: Scripts that do not return the correct number of DS' did not update properly
- bug: New forcerun option introduced in version 1.3 was causing boost not disable properly when you unselected it from the user interface.
— 1.4 —
- bug: Fixed an issue with data queries where the rrdupdate template was not formated correctly
— 1.3 —
- bug: Fixed an issue where multi part responses with a “0” would return “U”
- feature: Added better logging functions to help in debugging
- feature: Allow you to increase the MySQL Insert string length to improve performance
- feature: Allow you to increase the RRDtool update string length to improve performance
— 1.2 —
- bug: Added boost_server.php and poller_boost.php to the no session array
- bug: Made slight change to rrd-update functions to accommodate for aberrant output in the poller_output_boost table. This would cause the boost plugin to loose data if improperly formatted data made it into the table.
— 1.1 —
- bug: Fix issues with Multiprocess RRDupdating of RRD Files
— 1.0 —
- Initial release
- There is one known issue related to n'th percentile and Bandwidth summation. Prior to boost 3.0, the bandwidth summation and n'th percentile functions could fail. This has been corrected in Boost 3.0. However, the as of yet, unreleased PIA 2.7 will be required to take advantage of the new plugin hook function.