Here's an idea. Currently, MRTG will process all Targets until there are none left, using up all the available threads, and then sleep until the next polling cycle.
This can be problematic if you configure more targets, or there is an outage, and suddenly you do not have enough threads to process everything in the 5min window. Also, it results in a large burst of activity at the start of the window followed by silence. So, how about this - MRTG already knows how many targets there are, and the interval. It calculates x=(interval/#targets)x0.9 (the 0.9 is to allow time for the final checks to complete) and then kicks off a new Target to process every x seconds, starting a new thread if required (possibly up to a specified upper limit). This would possibly end up with each thread processing a single target and then exiting, with the master starting a new thread per Target. I think this may be how the Nagios check scheduler works? It would certainly solve the problems of (a) uneven CPU usage and (b) running out of window time when you add more targets but not more threads. The drawback is that, of course, you need to have sufficient CPU/memory to handle the potentially large number of threads that could result. Since Tobi is currently in a coding mood, I thought it best to get the suggestions in quick :) Steve ________________________________ Steve Shipway ITS Unix Services Design Lead University of Auckland, New Zealand Floor 1, 58 Symonds Street, Auckland Phone: +64 (0)9 3737599 ext 86487 DDI: +64 (0)9 924 6487 Mobile: +64 (0)21 753 189 Email: [email protected]<mailto:[email protected]> P Please consider the environment before printing this e-mail
_______________________________________________ mrtg-developers mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/mrtg-developers
