[Debian] Load blijft minimaal 1.00?

[Snow_King]

Hoi,

Ik zit met een raar probleem waar ik niet uit kom.

Mijn server heeft altijd een load van 1.00 en gaat maar niet lager.

Wat doet die server? Niets, hij staat hier namelijk nu echt NIETS te doen al dagen lang, maar de load blijft1.00

Met niets bedoel ik ook niets, er zit UTP in maar dat was het dan ook.

De setup:
- Debian 3.1 (Sarge)
- 2.4.28 Kernel
- Dual Opteron 242
- Tyan Thunder K8W (mobo)
- Areca ARC-1120 (RAID Controller)

Waarom geen 2.6.x kernel? Ik krijg de drivers van die Areca niet goed in de 2.6 kernel gebakken..

Maar dat is denk ik het probleem niet.

Even een voorbeeld

code:

fileserver:~# uptime
 23:19:22 up  1:24,  1 user,  load average: 1.00, 1.02, 1.01
fileserver:~#

Als ik "top" doe staat de hele tijd init bovenaan en zo af en toe komt mijn topje bovenaan te staan.

code:

Tasks:  48 total,   1 running,  47 sleeping,   0 stopped,   0 zombie
Cpu(s):   0.0% user,   0.2% system,   0.0% nice,  99.8% idle

Ik heb de bak al eens een reboot gegeven, maar de load blijft minimaal 1.00...

Opzich is het geen probleem, maar ik zou graag de load op 0.00 zien dat zodra hij echt aan het werk gaat dat ik wel een representatieve load krijg te zien en niet steeds -1 hoef te doen.

Wie weet waar dit aan zou kunnen liggen?

[CyBeR]

Zoek 's met 'ps' of je processen in 'D' status hebt, of anders met 'top' of je processen hebt die veel cpu gebruiken.

[Snow_King]

CyBeR schreef op zondag 26 december 2004 @ 23:24:
Zoek 's met 'ps' of je processen in 'D' status hebt, of anders met 'top' of je processen hebt die veel cpu gebruiken.

zoals ik al zei: "init staat altijd bovenaan in de top"

[ Voor 33% gewijzigd door Snow_King op 26-12-2004 23:31 . Reden: typo fix (sorry blaataap) ]

[CyBeR]

Woops, overheen gelezen. Status 'D' processen geldt echter nog steeds.

[blaataaps]

Snow_King schreef op zondag 26 december 2004 @ 23:25:
[...]


zoals ik al zei: "init staat altijd bovenaan in de top"

Dat komt doordat top default sorteert op cpu, en als tweede sorteerkey de PID zo te zien, die bij init "1" is, waardoor bij een idle systeem init bovenaanstaat, maar je geeft nog geen antwoord op de vraag of er ergens een proces met een rare state is. Dat is meestal de oorzaak van een hoge load, zonder merkbare belasting en een traag systeem. Vaak iets dat met filesystems/netwerken te maken heeft, een hangende nfs- of smbmount bijvoorbeeld.

[Snow_King]

CyBeR schreef op zondag 26 december 2004 @ 23:28:
Woops, overheen gelezen. Status 'D' processen geldt echter nog steeds.

ja, die is er wel

code:

10 root       9   0     0    0    0 D  0.0  0.0   0:00.00 arcmsr_kernel_t

arcmsr = driver raid controller

Hoe kan dat nou voor een minimum load van 1.00 zorgen?

[CyBeR]

Hoe dat precies komt weet ik niet, ik weet alleen dat 't zo is (hangende mounts hier bijvoorbeeld zijn ook een garantie voor hoge load zonder daadwerkelijke load.)

[Gwaihir]

Ik beheer een servertje dat dat precies zo heeft. (RedHat 8 trouwens, geen Debian.)

Nu: loads: 1,11 1,03 1,03
164 processes, 163 sleeping, 1 running (top), 0 zombie, 0 stopped.

Ik heb inderdaad één zo'n "D" process lopen: hpt_wt (IDE RAID driver). Wat houdt die status dan precies in? [Ik heb gelezen dat het "uninterruptible sleep" betekent en er staan CPU en MEM % van 0,0 bij, maar ondertussen blijft hij wel in de lijst staan wanneer ik met "i" de non-idle mode aanzet.]

[Snow_King]

Misschien nog boeiend om te weten.

De server heeft 7 ext3 partities en 1 reiserfs partitie, heeft dat er iets mee te maken?

De doorvoer is wel hoog van de disks, dat is het niet

code:

/dev/sda9:
 Timing cached reads:   1760 MB in  2.00 seconds = 880.00 MB/sec
 Timing buffered disk reads:  490 MB in  3.00 seconds = 163.33 MB/sec

Na hdparm -tT is de load dan 1.13, 0.13 gestegen dus.

Ik blijf dit erg frapant vinden...

[moto-moi]

Snow_King schreef op zondag 26 december 2004 @ 23:54:
De server heeft 7 ext3 partities en 1 reiserfs partitie, heeft dat er iets mee te maken?

Niet echt, ik heb een opteron bak staan met een reiserfs en een ext3 partitie, en die heeft een prima load van 0.00

Na hdparm -tT is de load dan 1.13, 0.13 gestegen dus.

Daar zou ik me niet al teveel zorgen over maken eigenlijk

Ik blijf dit erg frapant vinden...

Welke versie van Debian draai je eigenlijk ?
Ik heb de AMD64-tak erop gezet.

[usr-local-dick]

Hoi snowking

Ik heb het ook hier, met mijn areca server:
http://huge.cajones.org/sysinfo/

Het moet toch door die Areca driver komen, want dezelfde kernel deed het wel normaal vorige week toen mijn server nog op gewone ide diskjes draaide...

Ik zal dit voor de zekerheid nog een keer checken.

PS wat gaat er mis met die driver in 2.6 btw? bij mij zit ie er nl in (maar ik heb p4)

[ Voor 13% gewijzigd door usr-local-dick op 27-12-2004 11:33 ]

[Snow_King]

Met de 2.6 krijg ik compile errors (heb ze zo niet bij de hand) De 2.4 bakte zo in 1x zonder problemen.

het ligt dus aan de driver.

Zal dit een probleem zijn? De CPU's zijn immers 100% idle

[usr-local-dick]

Snow_King schreef op maandag 27 december 2004 @ 22:05:
Met de 2.6 krijg ik compile errors (heb ze zo niet bij de hand) De 2.4 bakte zo in 1x zonder problemen.

het ligt dus aan de driver.

Zal dit een probleem zijn? De CPU's zijn immers 100% idle

Ik moest wel een symlink maken van mijn kernelsource naar /usr/src/linux anders compilede ie hier ook niet, zal wel ergens hard ingeklopt staan in de driver source vrees ik...

[Snow_King]

ja, die symlink had ik ook gemaakt, maar dan werkt hij alsnog niet.

Ik zal even de kernel compilen, dan post ik de error zo hier.

EDIT:
de error

code:

In file included from drivers/scsi/arcmsr.c:87:
/usr/src/linux/drivers/scsi/hosts.h:1:2: warning: #warning "This file is obsolete, please use <scsi/scsi_host.h> instead"
drivers/scsi/arcmsr.c:173: error: unknown field `abort' specified in initializer
drivers/scsi/arcmsr.c:174: error: unknown field `reset' specified in initializer
make[3]: *** [drivers/scsi/arcmsr.o] Error 1
make[2]: *** [drivers/scsi] Error 2
make[1]: *** [drivers] Error 2
make[1]: Leaving directory `/usr/src/linux-2.6.10'
make: *** [stamp-build] Error 2

Het bestand scsi/scsi_host.h bestaat overigens niet, het enige wat er op lijkt is hosts.h, maarja die zegt een ander te moeten gebruiken.

[ Voor 74% gewijzigd door Snow_King op 29-12-2004 11:09 ]

[Snow_King]

* kleine onschuldige kick? *

Ik weet niet wat aan te gaan met die foutmelding.

[PowerSp00n]

code:

# ls -la /usr/src/linux-2.6.10/include/scsi/scsi_host.h
-rw-r--r--    1 500      500         18502 Dec 24 22:34 /usr/src/linux-2.6.10/include/scsi/scsi_host.h

Zoiets wellicht (verse 2.6.10)?

[RemcoDelft]

Dit soort dingen krijg je als Linux bijvoorbeeld IO-access wil, maar niet krijgt.
Stel, er is 1 disk kapot, en je doet een "ls" op die partitie, dan blijft-ie daarop wachten, dat verhoogt de load met 1, en dat blijft zo. Doe je nog een keer "ls", wordt de load 2, doe je het 30 keer, heb je load 30 ...

[Snow_King]

PowerSp00n schreef op donderdag 30 december 2004 @ 15:54:

code:

# ls -la /usr/src/linux-2.6.10/include/scsi/scsi_host.h
-rw-r--r--    1 500      500         18502 Dec 24 22:34 /usr/src/linux-2.6.10/include/scsi/scsi_host.h

Zoiets wellicht (verse 2.6.10)?

Helaas, het mocht niet baten.

code:

drivers/scsi/arcmsr.c:173: error: unknown field `abort' specified in initializer
drivers/scsi/arcmsr.c:174: error: unknown field `reset' specified in initializer
make[3]: *** [drivers/scsi/arcmsr.o] Error 1
make[2]: *** [drivers/scsi] Error 2
make[1]: *** [drivers] Error 2
make[1]: Leaving directory `/usr/src/linux-2.6.10'
make: *** [stamp-build] Error 2

Ik gebruik inderdaad 2.6.10

[usr-local-dick]

Ik gebruik hier 2.6.9 en die wil wel (op een woody systeem).
Misschien die eens proberen (2.6.10 is tenslotte het nieuwste en dat kan altijd betekenen dat je een bug gespot hebt..).
Of het moet aan je 64 bits verhaal liggen maar dat lijkt me sterk...
Ik heb net v.1.20.00.00 gemaild naar je, misschien dat dat uitmaakt.
succes

[ Voor 15% gewijzigd door usr-local-dick op 30-12-2004 18:23 ]

[Snow_King]

Mja, ik draai geen Debian 64bit, dus een 64bit driver gaat niet werken.

Ik heb ook 2.6.8 geprobeerd, maar geen resultaat.

Check jij je mail ook maar, je bent de bijlage vergeten

[usr-local-dick]

Snow_King schreef op donderdag 30 december 2004 @ 19:19:
Mja, ik draai geen Debian 64bit, dus een 64bit driver gaat niet werken.

Ik heb ook 2.6.8 geprobeerd, maar geen resultaat.

Check jij je mail ook maar, je bent de bijlage vergeten

gehe, er is wederom een niuewere versie uit, staat op hun site.
FYI bij 2.6 kernels moet je een iets andere procedure volgen volgens hun docje.
En heb je die driver wel als module? Ik meen me te herinneren dat hij niet 'hard' in een 2.6 wilde...
PS hier staat mijn 2.6.9 debje:klik
Deze heeft arcmsr als module, dus wel initrd gebruiken.

[Snow_King]

Ok, ik ga er eens mee stoeien.

[Snow_King]

Yes, mijn kernel is gebakken met de nieuwe drivers er in

Binnenkort naar RedBus en kijken of het lukt..

[ Voor 29% gewijzigd door Snow_King op 02-01-2005 22:49 ]

[Snow_King]

Ok, kernel is geboot met de nieuwe kernel (2.6.10), maar het probleem blijft.

Ik heb Areca gemaild over dit probleem.

[Verwijderd]

Yo het zit hem in de driver voor de RAID-Controller, die zorgt voor een load van 1.00 op je machine.
Hetzelfde probleem heb ik met een HighPoint RAID adaptertje in een RedHat 9.0 bakje.

Een upgrade van de RAID driver zou kunnen helpen, maar ja dan moet de leverancier wel meewerken.
Verders als je machine goede respons blijft geven dan is de load van 1.00 niet zo erg.
Je kan effe testen met hdparm -t of je machine op de RAID-Controller nog goede respons geeft.
De 1.00 load betekent dus niet een 100% CPU belasting, maar duidt op een thread die continue waiting is om iets nuttigs te kunnen doen. Op het moment dat de betreffende thread de CPU krijgt dan zal deze erachter komen dat er niets te doen is en vervolgens niet in de sleeping toestand gaan maar direct de waiting toestand aanroept.

suc6

[Snow_King]

ja, het is dus zeker de raid controller driver.

De load is dus wel erg aangezien de NFSd ook op status "D" komt en zo voor een hoge load zorgt en een vertraging.

het probleem schijnt hem in de SMP van de kernel icm de driver te zitten.

Ik ga eens een kernel maken met support voor 1 cpu, hopelijk werkt dat.

[Snow_King]

Ok, daar ben ik weer.

Het probleem zat hem niet in SMP support, dus ik ben gaan mailen met Areca.

Na mijn kernel te hebben opgestuurd en ook wat config files konden ze het probleem gelukkig nabootsen.

Ik heb nu een aangepaste versie van de driver gekregen waarmee het probleem over moet zijn.

De server is nu helaas in productie, dus ik moet een rustige nacht uitzoeken om die server even een reboot te geven.

Ik houd jullie op de hoogte.

[Snow_King]

Dit is dan mijn derde post achter elkaar, maar ik hoop dat dit niet vervelend is.

Zojuist heb ik de server gereboot met de 2.6.10 kernel en met die beta driver van hen er in en ja hoor, probleem opgelost.

Ik weet niet of Areca het goed vind dat ik de driver vrij geef, daarom geef ik nu ook geen linkje.

Wat ook frapant is, het hele proces arcmsr_kernel_t (dat op status D stond) bestaat nu niet meer.

Mijn probleem is dus opgelost!

[Sendy]

Lijkt me een complimentje waard hoe je het hebt opgelost. Je vraagt toch wel aan Areca of je de driver eventueel mag verspreiden (aan vrienden ofzo)?

En dat process is nu natuurlijk klaargekomen, dus dat verdwijnt uit je processlist [als ik de tread goed begrepen heb].

[Snow_King]

Ja, ok daar heb je gelijk in, daarom is het proces weg

Ik heb Areca direct nogmaals gemaild om te vragen of ik hem mag verspreiden.
Ik neem echter aan dat ze zeer spoedig een nieuwe versie van de driver releasen.

Mocht iemand de driver willen hebben, neem even contact met me op via wido (at) widodh.nl, als ik hem van Areca mag releasen stuur ik hem aan je door.