Newer 'boost' recipe for large installations?

[cjfournier]

I recently deployed boost 5.1 on a host polling 1000+ network devices. I used the howto article as reference, but there seemed to be some ambiguity around what indexes should be created (some generated mild errors.) I also note several people are using the boost server, as opposed to the memory option.

I was wondering if there was a newer version of this recipe (with db tweaks, a little more established.) I'm also wondering why people choose to use the boost server (and whether there's any performance advantage?)

[browniebraun]

I'm using Boost in our production environment (> 2000 hosts) since years. Boost heavily reduces the I/O load of your system,
which is in most cases the bottleneck Cacti, and other RRDtool based monitoring solutions, are struggling with
- especially if your company only allows you to have normal server hard disks.
Although my new server setup is connected to a high performance SAN (I/O waits: 0%) I never thought about
a removal of Boost. Boost additionally offers you to cache the RRD graphs and provides a Boost server that allows
to update the RRD files from remote and without providing write permissions to the user executing your Web Server.

Regards
-Andi

[cjfournier]

Sorry, I guess I wasn't clear on what I was asking -- 'boost' is awesome, but I used the article 'Cacti setup for really BIG environments' (http://forums.cacti.net/viewtopic.php?t=29707) as guide toward enabling this in a 0.8.8b instance.

Having followed the procedure, there seemed to be a few inconsistencies relative to what DB tweaks to apply, and/or what might change when using the newer version of the plugin. For example, I haphazardly applied the DB tweaks described in the link therein (http://bugs.cacti.net/view.php?id=1333), even though those are flagged as "fixed" in 0.8.8. And performance definitely jumped after having created the indexes (while some issued warnings, as I recall.)

What would be great to see is a newer version of the same guide, to better know what's still relevant and what isn't. I purposely provisioned all devices before enabling boost, to observe the effect of each change in the process. Prior to, the high powered server had a very hard time keeping up (load was in the vicinity of ~20.) The database changes alone (switch to Innodb + indexes), reduced the load to less than half (but again, not clear if any additional indexes, or tuning was appropriate.) Finally enabling 'boost' brought the load down even further.

So, even though it's keeping up with polling all of those devices (poller runtime is ~100s on average), some cycles are coming very close to the 300s mark. And while it's pretty amazing for it to be keeping up with that number of devices (having some ~250k data sources), I'm not convinced every possible tweak is in place, based on using an "old" recipe.

Regarding the last question, the guide advocates putting the database into RAM; I note that most recent forum postings on 'boost', suggest more people are using the boost server (instead.) I'm wondering why go this route (the db backup/restore piece, aside)?