Hello, > We also had this issue (40,000 targets) for a long time; tried tuning > commit which helps a bit but not much. Obviously the fastest disks you > can get help to reduce the bottleneck. RRD 1.4 helps a bit, though > noatime makes little difference.
I have already applied all these things. > You get significant savings by making sure MRTG is using daemon mode (as > opposed to using cron or similar) with RRD 1.4, so that the cfg files are > cached and the memory-mapped features of RRD1.4 kick in. I use CRON mode. Do you think, that memory-mapped features are not used in cron mode? I have over 1.2GB cached memory. It was worse with older RRDTool versions... > The main thing that fixed it for us was using rrdcached. However this > requires you to use the latest version of MRTG, plus the trunk version of > RRD 1.4 as well as the latest version of Routers2 (if you use this as the > frontend) and it has a couple of other caveats. I use 14all.cgi and my own index cgi and search engine. I don't want to much experiment on this production box. With rrdcached I will probably wait some time when it stabilize. > rrdcached is the read/write RRD caching daemon that goes between rrdtool > and the disk. You can tune it to be more or less aggressive and this has > a significant impact on disk I/O queues. Did you know about some filesystem tests? It will be better to use ext4 or btrfs for faster sync? Thank you. Best regards, Pavel _______________________________________________ mrtg mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/mrtg
