strange CPU load caused by Nagios
Mieden, Rick van der
rick.vandermieden at orangemail.nl
Mon Jul 25 16:50:47 CEST 2005
Hi all,
Nagios 2.0.3b causes a very high CPU load:
Hardware: 2x 1100 Mhz CPU with 1024 MB RAM
OS : Solaris 8 kernel patch 117350-05
When I do a top I get the following output:
last pid: 10261; load averages: 6.85, 7.40, 7.32
16:41:14
84 processes: 78 sleeping, 4 running, 2 on cpu
CPU states: 4.3% idle, 75.9% user, 19.3% kernel, 0.5% iowait, 0.0%
swap
Memory: 1024M real, 511M free, 238M swap in use, 2437M swap free
PID USERNAME THR PRI NICE SIZE RES STATE TIME CPU COMMAND
24512 netsaint 5 0 0 8808K 6608K sleep 7:42 1.63% nagios
10256 netsaint 1 0 0 8232K 7640K run 0:00 0.77%
check_snmp_stor
10224 netsaint 1 0 0 7664K 7080K sleep 0:00 0.75%
check_snmp_load
10259 netsaint 1 0 0 8176K 7584K cpu/0 0:00 0.70%
check_snmp_user
10229 netsaint 1 0 0 7520K 6936K sleep 0:00 0.61%
check_processes
10247 netsaint 4 0 0 16M 7744K sleep 0:00 0.19% sqlplus
10260 netsaint 3 0 0 8792K 6280K run 0:00 0.12% nagios
10250 netsaint 1 0 0 3600K 2792K run 0:00 0.07% ssh
1062 netsaint 1 59 0 3360K 1232K sleep 6:58 0.05% ssh-agent
1 root 1 58 0 856K 280K sleep 90:43 0.04% init
8138 apache 3 50 0 10M 2952K sleep 0:00 0.04% httpd
9176 netsaint 1 59 0 2824K 1704K cpu/1 0:00 0.04% top
10237 netsaint 1 0 0 2552K 1880K sleep 0:00 0.02%
check_oracle
10253 netsaint 3 0 0 8792K 1800K sleep 0:00 0.02% nagios
10245 netsaint 1 0 0 2552K 1224K sleep 0:00 0.02%
check_oracle
How is it possible that a proces nagios with only 5 LWPS can stress the
cpu to a load of 7. I can't find a way how to show this behaviour. Can
it be a system call thing?
A vmstat gives:
$ vmstat 5
procs memory page disk
faults cpu
r b w swap free re mf pi po fr de sr s0 s1 s2 -- in
sy cs us sy id
4 0 0 2582248 582960 546 375 5 5 4 0 0 0 8 0 0 311 1407 502 63
18 20
6 0 0 2527464 549280 440 7143 0 8 8 0 0 0 8 0 0 288 24273 401 85
15 0
6 0 0 2507096 535384 484 10244 0 0 0 0 0 0 0 0 0 342 31842 566 79
21 0
4 0 0 2508552 529336 574 10137 0 0 0 0 0 0 0 0 0 381 29564 612 74
23 4
3 0 0 2511568 537584 750 9249 0 6 4 0 0 0 7 0 0 340 27504 565 65
20 15
6 0 0 2528312 548208 588 10524 0 1 1 0 0 0 0 0 0 375 28649 590 73
23 4
6 0 0 2521848 541696 488 7871 0 0 0 0 0 0 16 0 0 304 28062 462 66
18 16
8 0 0 2519920 539080 576 8539 0 11 9 0 0 0 8 0 0 345 24551 521 79
18 3
8 0 0 2500472 530104 295 8656 0 0 0 0 0 0 0 0 0 323 30986 510 79
21 0
7 0 0 2497000 520200 786 9454 0 0 0 0 0 0 0 0 0 353 31087 560 72
22 7
I tuned the service_inter_check_delay_method parameter ( around 2600
services with 182 hosts) to the best value (so not having big latency)
to 0.45 sec.
Any suggestions?
Regards,
Rick
Met vriendelijke groet / Kind regards,
Orange Nederland N.V.
Rick van der Mieden
Unix engineer
Orange Nederland N.V.
Groenhovenstraat 2
Room 2C15
2596 HT Den Haag
Tel: +31 628 022771
Fax: +31 648 997173
Email: rick.vandermieden at orangemail.nl
===========================================================
De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is alleen bestemd voor de geadresseerde. Indien u dit bericht onterecht ontvangt, wordt u verzocht de inhoud niet te gebruiken en de afzender direct te informeren door het bericht te retourneren. Hoewel Orange maatregelen heeft genomen om virussen in deze email of attachments te voorkomen, dient u ook zelf na te gaan of virussen aanwezig zijn aangezien Orange niet aansprakelijk is voor computervirussen die veroorzaakt zijn door deze email.
The information contained in this message may be confidential and is intended to be only for the addressee. Should you receive this message unintentionally, please do not use the contents herein and notify the sender immediately by return e-mail. Although Orange has taken steps to ensure that this email and attachments are free from any virus, you do need to verify the possibility of their existence as Orange can take no responsibility for any computer virus which might be transferred by way of this email.
===========================================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-lists.org/archive/users/attachments/20050725/c062cdf2/attachment.html>
More information about the Users
mailing list