|
> > I'm not disputing that your system is able to cope with the
> > load you are
> > putting on it. I'd to note that much of the CPU time that LVS
> > uses is done
> > within the kernel and as such it will not show up in a load
> average or
> > %CPU utilisation as shown by top and friends. This is because
> > cycles used
> > within the kernel more or less disappear from userspace,
> > throwing the stats
> > out.
I believe I remember hearing a few times that you can use ucd-snmp and mrtg
to get load. The best way I know of to keep track of these numbers in a
meaningful fashion is to use mrtg. (you're using lvsgrp+mrtg for connection
totals anyway in your LVS cluster, right?). I believe the UCD-load SNMP
function gets total CPU as found in /proc/stat, which is probably what you
are looking for (load of machine, who cares what uses what - right?).
The disucssions in the past seem to indicate that /proc/stat is a good way
of keeping track of actual load. Snipped from the archive ....
{{ post on sept 10 to LVS archives }}
> > Unfortunately for some reason
> > that no-one has explained to me "top/system" doesn't see everything.
> > I can have a VS-DR director which is running 50Mbps on a 100Mpbs link
> > and the load average doesn't get above 0.03 and system to be
> > negligable. I would expect it to be higher.
>
> Yes, the column is named "%CPU", i.e. the CPU spend for
> one process related to all processes. As for the load average, it is
> based on the length (number of processes except the current one) of
> the queue with all processes in running state. As we know, LVS does
> not interract with any processes except the ipvsadm. So, the normal
> mode is the LVS box just to forward packets without spending any CPU
> cycles for processes. This is the reason we to see load average 0.00
>
> OTOH, vmstat reads /proc/stat and there are the counters
> for all CPU times. Considering the current value for jiffies (the
> kernel tick counter) the user apps can see the system, the user and
> the idle CPU time. LVS is somewhere in the system time. For more
> accurate measurement for the CPU cycles in the kernel there are some
> kernel patches/tools that are exactly for this job - to see what time
> takes the CPU in some kernel functions.
>
> > Joe
>
> Regards
>
> --
> Julian Anastasov <ja@xxxxxx>
Hope that helps,
Peter
|
