[mrtg] Intermittent Graphs

Darren.Terry at cox.com Darren.Terry at cox.com
Sat Feb 2 19:37:14 CET 2008

-----Original Message-----
From: mrtg-bounces at lists.oetiker.ch
[mailto:mrtg-bounces at lists.oetiker.ch] On Behalf Of Nico Kadel-Garcia
Sent: Saturday, February 02, 2008 12:32 PM
To: mrtg at lists.oetiker.ch
Subject: Re: [mrtg] Intermittent Graphs

Alex van den Bogaerdt wrote:
> On Sat, Feb 02, 2008 at 08:55:46AM -0500, Darren.Terry at cox.com wrote:
>>      This past week I migrated a very, very large MRTG installation
>> new servers and updated software. Everything went well with the
>> relocation with the exception of one group of hardware. The group of
>> CMTS systems that I am graphing aren't graphing correctly. They have
>> graphs which are very intermittent. They look like saw blades. I
>> the reason that they are so intermittent is that the poll isn't
>> finishing before the next one needs to start. So, I am receiving the
>> lock file error in email. However, this doesn't make sense. I
>> to servers that are LEAST five times stronger. In addition to this,
>> according to the FAQ on the MRTG site, the graphs should be populated
>> with the previous data rather than zero.
>> 	If anyone has any ideas about how to speed up the poll or
>> anything else that might help, I am all ears (or eyes?)!! 
> Lock file errors, meaning it takes too much time to finish one round,
> and the next one is started before the prevous one has finished.
> Perhaps two polling periods is enough for those counters to wrap
> around, similarly to the infamous 114Kbps at 5-minute intervals.
> Things to try:
> * increase IO speed
> * use HC counters
> * run multiple MRTG instances parallel
> A temporary workaround may be to increase the polling interval from
> five to six minutes (or maybe seven), but not to ten as that would
> most likely will result in more, not less, saw blade-looking.
> Alex
This is compounded by unpingable routers, that introduce massive delays 
into the polling. Breaking up mrtg into checks of small numbers of 
machines is handy: running a pre-check with "ping" or the Nagios 
"check_alive" tool before running MRTG on a target is also handy.

mrtg mailing list
mrtg at lists.oetiker.ch

Thanks for everyone's help!

	I migrated from Linux 32-bit-> Linux 64-bit
	The drives being used are 15K RPM 146GB SAS drives. Both servers
are dual core, dual processor Xeons running at 2.33GHz. The load
averages on the servers never go above 2 when mrtg is running. I am
currently running 4 parallel processes on these devices. Most of the
devices wont support HC counters. I am going to try and bump up the
polling interval to 6 minutes.

	Thanks for your help...advise is welcome!! 

More information about the mrtg mailing list