Hi,
I'm currently have about 200+ graphs from 30 routers in Cacti. I will have ~3000 graphs and 400+ routers after said and done. Can one machine handle the load providing that Cacti is not used for polling. I 'm using cricket and smokeping to poll the devices from 2 machines. The cacti machines will nsf mount the rrd files from different pollers and provide the GUI to the users.
Thanks..
system load
Moderators: Developers, Moderators
Obviously you need a kick-butt machine to do this job.
Your careful structuring of the cacti tree hierarchy will greatly influence your load at page generation time. If you're doing all this under a single cacti web site instance, then imagine what would happen if you open the graphs preview page and it has to generate the 3000 graphs... over and over again. Imaging just several of these users doing the same. Okay, if you can group them carefully under a tree layout and NOT keep all the branches open, limiting the on-the-fly generation of the graphs to some reasonable level (maybe upto a few hundred pending your hardware) you might have some success. But someone is going to open them all at some point and that will be a pain. As you're not doing the data collection with cacti, it would seem that the 5 minute cycle time of doing data collection would not present a problem. You might consider generating the static png files and let the user base access those to improve efficiency. I find that because a user accesses the static pages that the browser can go back easily whereas with cacti on-the-fly graph generation, it gets slow to have to wait for the page update. Something tells me that NFS will tend to throttle your performance also. I'd consider trying it with NFS access to the rrd files, but also I'd be prepared to try it with a local copy of the files... You'd have to test out the performance tradoffs. I recollect that someone posted some performance tips where they created some extra indexes in the mysql database and that greatly helped with performance issues. I don't know if Rax/Ian ever incorporated those things into the current release of cacti.
I'm currently using cacti in a US Bank for monitoring/graphing Unix system performance metrics by using (currently and growing) 15 instances of cacti, each having a 5 minute crontab entry, doing their data collection thing. There are usually about 12 graphs per machine and some of the instances generate upwards of 140 graphs and the data collection interval seems to fit/work comforably. Have not had any 5 minute overflows as of yet. It's done one a Sun 3500 6way machine with 5GB ram and more than adaquate disk arrays... Currently there are 512 (cooincidence) rrd files. My static_graphs directory has 15 instance subdirectories containing 3575 .PNG files which seems to be about 893 graphs (with 4 views per graph). Almost all of the data collection is done by means of using our own extensions to netsaint_statd (a perl script that executes as a daemon and is installed on everything here and is used by the OSS NetSaint network/systems monitor package for NNM purposes and I submitted all that code to rax so it could get posted and it's never been seen since). We also use some snmp for graphing the interfaces, but the netsaint_statd method is working great for most other stuff. It lets us use standard NetSaint(aka Nagios) to monitor for problems and generate alerts to admins and stuff while cacti collects data from the same daemon to provide trending and visualization of all the data. Thus, NetSaint and Cacti are to us, complementary packages. Cacti is awesome and Rax/Ian has done and is doing a great job!
Your careful structuring of the cacti tree hierarchy will greatly influence your load at page generation time. If you're doing all this under a single cacti web site instance, then imagine what would happen if you open the graphs preview page and it has to generate the 3000 graphs... over and over again. Imaging just several of these users doing the same. Okay, if you can group them carefully under a tree layout and NOT keep all the branches open, limiting the on-the-fly generation of the graphs to some reasonable level (maybe upto a few hundred pending your hardware) you might have some success. But someone is going to open them all at some point and that will be a pain. As you're not doing the data collection with cacti, it would seem that the 5 minute cycle time of doing data collection would not present a problem. You might consider generating the static png files and let the user base access those to improve efficiency. I find that because a user accesses the static pages that the browser can go back easily whereas with cacti on-the-fly graph generation, it gets slow to have to wait for the page update. Something tells me that NFS will tend to throttle your performance also. I'd consider trying it with NFS access to the rrd files, but also I'd be prepared to try it with a local copy of the files... You'd have to test out the performance tradoffs. I recollect that someone posted some performance tips where they created some extra indexes in the mysql database and that greatly helped with performance issues. I don't know if Rax/Ian ever incorporated those things into the current release of cacti.
I'm currently using cacti in a US Bank for monitoring/graphing Unix system performance metrics by using (currently and growing) 15 instances of cacti, each having a 5 minute crontab entry, doing their data collection thing. There are usually about 12 graphs per machine and some of the instances generate upwards of 140 graphs and the data collection interval seems to fit/work comforably. Have not had any 5 minute overflows as of yet. It's done one a Sun 3500 6way machine with 5GB ram and more than adaquate disk arrays... Currently there are 512 (cooincidence) rrd files. My static_graphs directory has 15 instance subdirectories containing 3575 .PNG files which seems to be about 893 graphs (with 4 views per graph). Almost all of the data collection is done by means of using our own extensions to netsaint_statd (a perl script that executes as a daemon and is installed on everything here and is used by the OSS NetSaint network/systems monitor package for NNM purposes and I submitted all that code to rax so it could get posted and it's never been seen since). We also use some snmp for graphing the interfaces, but the netsaint_statd method is working great for most other stuff. It lets us use standard NetSaint(aka Nagios) to monitor for problems and generate alerts to admins and stuff while cacti collects data from the same daemon to provide trending and visualization of all the data. Thus, NetSaint and Cacti are to us, complementary packages. Cacti is awesome and Rax/Ian has done and is doing a great job!
Who is online
Users browsing this forum: No registered users and 1 guest