Vmstat graph on redhat as 2.1 & 3
thomas.seglard.enata at cnp.fr
thomas.seglard.enata at cnp.fr
Wed Mar 22 16:39:34 CET 2006
Hi,
I see strange vmstat graphs on these 2 Oses : Redhat AS 2.1 (ia32) and
Redhat AS 3 (ia32 and ia64). It seems that some columns were inverted or
shifted, here is the output of vmstat on a redhat 2.1 :
procs memory swap io system cpu
r b w swpd free buff cache si so bi bo in cs us sy id
10 0 0 4828 12240 74940 36412 0 0 0 0 0 0 0 0 0
1 0 0 4828 13000 74940 36424 0 0 0 90 141 189 15 21 65
0 0 0 4828 13000 74940 36424 0 0 0 0 129 27 0 0 100
0 0 0 4828 13100 74940 36420 0 0 0 12 138 31 1 0 99
0 0 0 4828 13100 74940 36420 0 0 0 0 129 21 0 0 100
and another one from a redhat 3 :
procs memory swap io system cpu
r b swpd free buff cache si so bi bo in cs us sy
wa id
91 0 4791520 31616 466384 1412464 10 27 58 89 552 7022 36 9 7 48
1 0 4791520 34576 466384 1412832 0 0 0 266 5473 19909 25 23 0 52
1 0 4791520 31792 466384 1412816 0 0 0 8 5716 18403 23 5 0 72
2 0 4792560 32512 466384 1411840 0 347 0 540 5496 18243 33 9 0 58
3 0 4792560 32512 466384 1411936 0 0 0 132 5139 17295 18 5 0 77
0 0 4792560 32608 466400 1412032 0 0 0 13 5106 17191 19 7 0 74
It seems graphs don't care about the idle column. I put the output from a redhat as 4 (update 2) :
procs -----------memory---------- ---swap-- -----io---- --system--
----cpu----
r b swpd free buff cache si so bi bo in cs us sy
id wa
0 0 96 44128 217952 3371248 0 0 1 17 0 0 1 0 98 0
0 0 96 44064 217952 3371248 0 0 0 12 2080 55 0 0 100 0
0 0 96 44064 217952 3371248 0 0 0 24 2076 48 0 0 100 0
0 0 96 44128 217952 3371248 0 0 0 12 2080 54 0 0 100 0
0 0 96 54240 217952 3371248 0 0 0 17 2073 54 0 0 100 0
On this particular os, vmstat graphs are ok. On a Debian 3.1 system,
graphs look good too.
So, what can I do ? Is there a file to modify, a package to install ?
Remove Redhat and install a Debian...
Regards,
Thomas Seglard
"Jeff Newman" <jeffnewman75 at gmail.com> a écrit sur 10/03/2006 00:37:57 :
> Ill be very generic and vague here, because I don't have much time,
> but I hope it helps point you in the right direction.
>
> What I have done is create a "high-flow xxx" new test, because, you
> have to re-do the RRD file with the different step interval.
>
> I would then copy the existing http test, and then write a wrapper
> that throws the script into an infinite loop like:
>
> while true; do
> /usr/local/hobbit/client/ext/httptest.sh
> sleep 1
> done
>
> and put that wrapper script into the hobbitclient conf. script in
> the etc dir.
>
> Then you'll have to configure the custom test on the server, the
> same way you would any other. (Following Henrik's guide he has
> posted to the group before)
>
> Just make sure you create the RRD file yourself FIRST. As Henrik has
> stated, hobbit will happily update a pre-existing RRD file. If you
> let hobbit create the RRD, it will do it at a 5 minute step rate.
>
> -Jeff
>
>
> On 3/9/06, Marsh, Ian <ian.marsh at hants.gov.uk> wrote:
>
> We're currently experiencing a problem with httpd on one of our
> servers that isn't being caught by hobbit. Is it possible to specify
> a custom test interval for just one test on one server? The hope is
> that it'll stand a better chance of catching the problem if it runs,
> say, every minute rather than every 5 minutes.
> Thank you,
> Ian Marsh
>
> IT Services, Network Services
> Hampshire County Council
> Telephone: 01962 845235
> HPSN: 200 5235
> em ail: ian.marsh at hants.gov.uk
Ce message (et toutes ses pieces jointes eventuelles) est confidentiel et etabli a l'intention exclusive de ses destinataires.
Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est
interdite, sauf autorisation expresse.
L'internet ne permettant pas d'assurer l'integrite de ce message, CNP Assurances et ses filiales declinent toute responsabilite
au titre de ce message, s'il a ete altere, deforme ou falsifie.
*****
This message and any attachments (the "message") are confidential and intended solely for the addressees.
Any unauthorised use or dissemination is prohibited.
E-mails are susceptible to alteration.
Neither CNP Assurances nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20060322/ed829ec8/attachment.html>
More information about the Xymon
mailing list