[CentOS5.5]wel load, maar weinig cpu/disk gebruik?

Pagina: 1
Acties:

Acties:
  • 0 Henk 'm!

  • axis
  • Registratie: Juni 2000
  • Laatst online: 26-01-2023
Ik heb een Dell PowerEdge 860 als dedicated nagios bak.

Wat me opvalt is dat deze machine gemiddeld een load heeft van rond de 1, terwijl CPU en disk uit hun neus eten.. CPU is ~90% idle volgens top (dual core Xeon 3060):
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
top - 13:26:41 up 3 days,  2:02,  1 user,  load average: 1.15, 0.94, 0.91
Tasks: 155 total,   1 running, 154 sleeping,   0 stopped,   0 zombie
Cpu(s):  2.2%us,  3.8%sy,  0.0%ni, 93.5%id,  0.2%wa,  0.2%hi,  0.2%si,  0.0%st
Mem:   2059264k total,  1482924k used,   576340k free,   179876k buffers
Swap:  2096376k total,        0k used,  2096376k free,   501712k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
12038 nagios    15   0  127m  27m 2404 S  1.7  1.4  43:27.58 nagios
20864 named     25   0  160m 4728 2016 S  0.3  0.2   4:28.17 named
29520 root      15   0 12744 1112  808 R  0.3  0.1   0:00.03 top
    1 root      15   0 10352  704  588 S  0.0  0.0   1:05.44 init
    2 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 migration/0
    3 root      34  19     0    0    0 S  0.0  0.0   0:00.00 ksoftirqd/0
    4 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 watchdog/0
    5 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 migration/1


De disks doen ook niet veel, een iostat -x met interval van 10sec geeft aan dat de disks 1% bezig zijn. (alles staat op /dev/md0, een raid1 over sda en sdb):
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           6.96    0.00    6.16    0.00    0.00   86.89

Device:         rrqm/s   wrqm/s   r/s   w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00    53.95  0.00 15.08     0.00   552.25    36.61     0.19   12.78   0.82   1.24
sda1              0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sda2              0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sda3              0.00    53.95  0.00 15.08     0.00   552.25    36.61     0.19   12.78   0.82   1.24
sdb               0.00    53.85  0.00 15.18     0.00   552.25    36.37     0.19   12.78   0.87   1.32
sdb1              0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sdb2              0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sdb3              0.00    53.85  0.00 15.18     0.00   552.25    36.37     0.19   12.78   0.87   1.32
md2               0.00     0.00  0.00 68.43     0.00   547.45     8.00     0.00    0.00   0.00   0.00
md1               0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
md0               0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00


Hier nog wat historische stats uit cacti:
Afbeeldingslocatie: http://files.hongens.nl/2010/12/20/til-ipm-01-stats.png

Iemand enig idee hoe ik erachter kan komen waar die load vandaan komt?

edit: cpu info toegevoegd

Two advices for network troubleshooting.. learn to draw diagrams in Visio, and THINK IN LAYERS!


Acties:
  • 0 Henk 'm!

  • deadinspace
  • Registratie: Juni 2001
  • Laatst online: 06-10 13:38

deadinspace

The what goes where now?

axis schreef op maandag 20 december 2010 @ 13:38:
Hier nog wat historische stats uit cacti:
[afbeelding]
Wat me zomaar opvalt (geen flauw idee of het gerelateerd is aan je vraag): je geheugengebruik stijgt langzaam maar gestaag. Kun je eens in top kijken naar de grootste geheugenvreters (sorteren op geheugengebruik met shift-M), die ergens noteren en een dag (ofzo) later kijken of daar wat veranderd is?

Verder zou ik graag eens de output van
ps auxf

zien.

Acties:
  • 0 Henk 'm!

  • Foeijonghaai
  • Registratie: Juli 2001
  • Laatst online: 24-09 14:52
Load 'betekent': het aantal processen dat klaar staat in de run-queue om gebruik te willen maken van de processor. Niet meer, niet minder. Het zegt dus niets over disk- of cpu-gebruik.

Als je echt wil weten wat er allemaal gebeurt op je systeem: installeer eens process accounting (acct) of atop, een uitgebreidere variant van top waarmee veel meer zichtbaar is en meer geregistreerd wordt.

Je kan een machine hebben met 40 processen en een load van 10 maar ook een machine met 4000 processen met een load van 1.

Wat er vermoedelijk aan de hand is: nagios spawnt per 5 minuten een x aantal processen om resources te monitoren. Dan heb je tijdelijk een hoge load (al die processen willen op de CPU) (en hoog cpu verbruik). Na verloop van tijd zijn er steeds meer processen klaar. De load zal richting 0 zakken. Na verloop van tijd zakt ook de CPU usage. Vijf minuten zijn voorbij. Verhaal begint weer van voor af aan.

Acties:
  • 0 Henk 'm!

  • axis
  • Registratie: Juni 2000
  • Laatst online: 26-01-2023
Ah, weer wat geleerd, met die shift+M zie ik dat nagios een heleboel child threads start die na een seconde weer stoppen:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
top - 14:25:42 up 3 days,  3:01,  1 user,  load average: 1.04, 1.03, 0.99
Tasks: 179 total,   1 running, 178 sleeping,   0 stopped,   0 zombie
Cpu(s): 10.6%us,  8.8%sy,  0.0%ni, 80.4%id,  0.0%wa,  0.2%hi,  0.0%si,  0.0%st
Mem:   2059264k total,  1631940k used,   427324k free,   180056k buffers
Swap:  2096376k total,        0k used,  2096376k free,   505540k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 4732 root      18   0  682m 172m  10m S  0.0  8.6   0:42.44 dsm_om_connsvcd
12038 nagios    15   0  127m  27m 2404 S  3.0  1.4  44:05.98 nagios
31486 nagios    15   0  127m  25m  144 S  0.0  1.3   0:00.00 nagios
31490 nagios    16   0  127m  25m  144 S  0.0  1.3   0:00.00 nagios
31494 nagios    19   0  127m  25m  144 S  0.0  1.3   0:00.00 nagios
31498 nagios    18   0  127m  25m  144 S  0.0  1.3   0:00.00 nagios
31502 nagios    18   0  127m  25m  144 S  0.0  1.3   0:00.00 nagios
31506 nagios    17   0  127m  25m  144 S  0.0  1.3   0:00.00 nagios
31510 nagios    17   0  127m  25m  144 S  0.0  1.3   0:00.00 nagios
31514 nagios    18   0  127m  25m  144 S  0.0  1.3   0:00.00 nagios
31518 nagios    21   0  127m  25m  144 S  0.0  1.3   0:00.00 nagios
31522 nagios    20   0  127m  25m  144 S  0.0  1.3   0:00.00 nagios
31526 nagios    20   0  127m  25m  144 S  0.0  1.3   0:00.00 nagios
31530 nagios    19   0  127m  25m  144 S  0.0  1.3   0:00.00 nagios
31534 nagios    19   0  127m  25m  144 S  0.0  1.3   0:00.00 nagios
31538 nagios    20   0  127m  25m  144 S  0.0  1.3   0:00.00 nagios
31542 nagios    21   0  127m  25m  144 S  0.0  1.3   0:00.00 nagios
31546 nagios    24   0  127m  25m  144 S  0.0  1.3   0:00.00 nagios
31550 nagios    22   0  127m  25m  144 S  0.0  1.3   0:00.00 nagios
31574 nagios    25   0  127m  25m  144 S  0.0  1.3   0:00.00 nagios
31578 nagios    25   0  127m  25m  144 S  0.0  1.3   0:00.00 nagios

En een second later is het weer anders.

Met px auxf zie ik dit ook terug, elke check is een eigen child proces. Ik ga eens even verder zoeken, heb al wat andere sites gevonden over nagios performance tuning, wellicht kan het allemaal efficienter.

Two advices for network troubleshooting.. learn to draw diagrams in Visio, and THINK IN LAYERS!


Acties:
  • 0 Henk 'm!

  • axis
  • Registratie: Juni 2000
  • Laatst online: 26-01-2023
Foeijonghaai schreef op maandag 20 december 2010 @ 14:25:
Wat er vermoedelijk aan de hand is: nagios spawnt per 5 minuten een x aantal processen om resources te monitoren. Dan heb je tijdelijk een hoge load (al die processen willen op de CPU) (en hoog cpu verbruik). Na verloop van tijd zijn er steeds meer processen klaar. De load zal richting 0 zakken. Na verloop van tijd zakt ook de CPU usage. Vijf minuten zijn voorbij. Verhaal begint weer van voor af aan.
Ik weet wel iets over load, maar je vraagt je dan op een gegeven moment wel af waarom die threads in de queue staan.. Er zal toch ergens een bottleneck moeten zijn.

Nagios spreid de load over die 5 minuten. We hebben rond de 1200 checks, dus hij probeert dan uit te komen op rond de 4 checks per seconde. Dat verklaart waarom dat de load iig netjes constant is.

Two advices for network troubleshooting.. learn to draw diagrams in Visio, and THINK IN LAYERS!


Acties:
  • 0 Henk 'm!

  • pjottum
  • Registratie: Mei 2000
  • Laatst online: 22:56

pjottum

¯\_(ツ)_/¯

Heb je nog een dood procesje draaien? Zoek even met ps aux | grep " D "
Soms blijft er iets hangen - en sterft niet af.. Houdt wel 1 plekje in de runqueue bezet.

ping 127.212.23.124


Acties:
  • 0 Henk 'm!

  • axis
  • Registratie: Juni 2000
  • Laatst online: 26-01-2023
Heb nog wat getweakt in nagios.. onder andere de setting 'large_installation_tweaks' aangezet, waardoor nagios anders omgaat met processen (zoals bijvoorbeeld processen niet actief killen, maar overlaten aan os), en nu is de load al gezakt naar 0.3 gemiddeld.. Ik vind het wel weer prima, wel in dit topic nieuwe truukjes geleerd (Zoals ps auxf, etc).

Two advices for network troubleshooting.. learn to draw diagrams in Visio, and THINK IN LAYERS!

Pagina: 1