[mrtg] Re: Long Polling Times?

Wed Apr 5 23:52:27 MEST 2000

"Chastain, Brian (I.T. Dept)" wrote:
> 
> Gentlemen/Ladies,
>      I'm currently monitoring 37 ports with my mrtg.cfg file, and am
> planning to add about another 20.  

So roughly your processing time will increase by 50%

>      I'm using MRTG 2.8.12 on an NT PC with 128MB of RAM and a PIII-500
> processor.

Only MRTG?

>      It seems to take 6 to 7 minutes for the mrtg.cfg file to process.  Or,
nope... not 7 minutes.  It is 2 minutes. (at least, if you are running MRTG
every 5 minutes.  If not, you should have told it).

> rather, a gif file will say "last updated at 10:30" one time, then "last
> updated at 10:37" the next time.
>      Should this be a concern?  Is this normal?  

That depends on what the box is doing ... If you start a heavy job (other
than the MRTG job) somewhere between 10:31 and 10:37 then yes, this would
be normal (or rather: expected).

Also: if the job which started at 10:25 takes *too* long and only finishes
at 10:30, this 10:30 is not nice at all ...  If OTOH the job which started
at 10:30 is the one that finishes at 10:30 I wouldn't worry too much about
the load yet. Notice the difference here.  The first case is 5 minutes, the
second case is 0 minutes...

>      Does the difference in display time correspond to the amount of time it
> takes the mrtg.cfg file to process?

If processing the job does not take any time at all, you will see a
difference of 5 minutes...  If processing takes 4 minutes for the first time
and no time at all the second time, you will see a difference of 5 minutes.
If the first run takes no time at all and the second run takes 4 minutes
you will see a difference of 9 minutes.

In your case there are two possible scenarios: (as far as I can reason)
1) job #1 took no time (when measured in minutes) and job #2 took 2 minutes
2) job #1 took 5 minutes, job #2 was skipped, job #3 took 2 minutes

Processing time may be the same (may be not...) but if there is
more to do than only MRTG then the MRTG process will not get every cpu cycle.
In other words, the job may still use only a few seconds while it is running
for 2 minutes.  During those 2 minutes another process uses a lot of cpu
and MRTG has to wait.

>      I've saw the email thread a week or two ago discussing "How much is too
> much?" when it comes to monitoring.
>      I don't think there was really any consensus.
>      I guess my main question would be, can MRTG keep viable statistics as
> the processing time increases; or does the process time relate at all to the
> "last updated..." display?

IMHO the outcome was: "it depends".
Do you use MRTG for billing or similar purposes: yes, you should consider
moving some load to another box.
If you use MRTG for long term trend reporting: no problem.

MRTG is resistent to being started at varying times as long as the real
run time is constant.  If it takes the same amount of time to take a sample
each time, there is no error:

1) collect the data
2) generate a time stamp
3) update the database (the log file) using the outcome of (1) and (2)

Step 1 and step 2 are not close together in the process.  If there is a
variable delay inbetween them, there is an error introduced.  It is not
a problem if there is a delay between steps 2 and 3. 

For the next target, you start again at (1).  The delay between the last
(3) and the next (1) is also not introducing any error.  This delay does
contribute to the total run time of the script.

If the total running time of the script is 5 minutes or above, MRTG will
not start for that interval.  This is not a problem (for recent versions)
as it will know that the increase of the counters happened in 10 minutes.
It will therefore divide the increase by 600 and get the same average of
bits per second as it would normally have gotten for the two intervals of
5 minutes.  The only error introduced by this is:

time 00:00 counter at 100,000,000
time 00:05 counter at 100,300,000
time 00:10 counter at 101,200,000

Normal polling happens:
time 00:05 increase is 300,000 in 300 seconds -> store 1 kBps
time 00:10 increase is 900,000 in 300 seconds -> store 3 kBps
Result:
time 00:05 line utilization == 1 kBps
time 00:10 line utilization == 3 kBps

The poll at 00:05 is not executed:
time 00:05 --> no info
time 00:10 increase is 1,200,000 in 600 seconds -> store 2 kBps for
           both intervals
Result:
time 00:05 line utilization == 2 kBps
time 00:10 line utilization == 2 kBps

> Thanks for your help,

Hope it was help ...

regards,
-- 
   __________________________________________________________________
 / alex at slot.hollandcasino.nl                  alex at ergens.op.het.net \
| work                                                         private |
| My employer is capable of speaking therefore I speak only for myself |
+----------------------------------------------------------------------+
| http://faq.mrtg.org/                                                 |
| http://rrdtool.eu.org  --> tutorial                                  |
+----------------------------------------------------------------------+

--
Unsubscribe mailto:mrtg-request at list.ee.ethz.ch?subject=unsubscribe
Archive     http://www.ee.ethz.ch/~slist/mrtg
FAQ         http://faq.mrtg.org    Homepage     http://www.mrtg.org