[Debian] Processen gaan naar status D

[Snow_King]

Hallo,

Ik heb hier een aardig leuk Debian systeem, maar helaas vertoond deze wat kleine problemen.

Allereerst de opstelling:
- Dual Opteron 242
- Tyan Thunder K8W
- 2GB DDR
- 8x Maxtor Diamondplus 10 (RAID5 + 1 hotspare)
- Areca ARC-1120 raid controller
- 2x Gbit NIC
- Kernel 2.6.10

Nu is het als volgt.

De server dient als NFS server en doet dat allemaal best goed, maar soms (lees in de avond rond spitsuur) gaat de status van veel nfsd processen naar status 'D' in top.

Ik kan vanaf die server zonder problemen downloaden, ik haal met gemak 10mb/sec, dat is echt geen probleem.

Nu dacht ik dat dit aan NFS lag, maar nu voerde ik een script uit waar ongeveer 5000 directories mee gechowned moeten worden met chown.
Tot mijn verbazing ging de load van de server van 0.05 naar 8.90 toe en ja hoor, in de top ging chown naar status D toe.

code:

Tasks:  67 total,   1 running,  66 sleeping,   0 stopped,   0 zombie
Cpu(s):  1.2% us,  2.8% sy,  0.0% ni,  4.3% id, 91.2% wa,  0.2% hi,  0.3% si
Mem:   2075596k total,   965052k used,  1110544k free,   810060k buffers
Swap:  4882408k total,       40k used,  4882368k free,    61932k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
19016 root      18   0  2112  756  556 D  1.3  0.0   0:00.04 chown
16093 root      15   0     0    0    0 D  0.7  0.0   1:26.56 nfsd
16086 root      15   0     0    0    0 D  0.7  0.0   1:26.24 nfsd
  158 root      15   0     0    0    0 S  0.3  0.0   8:27.64 kswapd0
16087 root      15   0     0    0    0 D  0.3  0.0   1:23.21 nfsd
    1 root      16   0  1500  516  456 S  0.0  0.0   0:00.45 init

Zoals je zit staat de CPU 91,2% op waiting!

het filesystem (/home) is reiserfs en bevat eigenlijk alleen maar kleine files.
/home is op dat systeem de meest gebruikte partitie, daar gaat alle data doorheen.

hdparm -tT zegt

code:

Timing cached reads:   2500 MB in  2.00 seconds = 1249.56 MB/sec
Timing buffered disk reads:   80 MB in  3.10 seconds =  25.79 MB/sec

Nu is dat echt om te huilen aangezien ik een week geleden nog lekker 150MB/sec haalde bij buffered disk reads.

EDIT
Doe nu net nog eens hdparm

code:

Timing cached reads:   2704 MB in  2.00 seconds = 1351.53 MB/sec
Timing buffered disk reads:  556 MB in  3.02 seconds = 184.19 MB/sec

/var/log/messages? Niets raars
/var/log/syslog? Niets raars
dmesg? Ook niets raars

Waar duidt dit op?
- Te trage harddisks?
- Driver probleem?
- Kernel probleem?

Dit topic is eigenlijk een navolging van: [rml][ Debian] Load blijft minimaal 1.00?[/rml]

[ Voor 12% gewijzigd door Snow_King op 25-01-2005 11:58 ]

[Kees]

Heb je bij de instellingen voor de raidcard de optie uit write-back / write-thru caching?
En read-ahead / adaptive / cached read / no cache etc voor de reads?

[Snow_King]

Daarvoor moet ik neem ik aan in de bios van mijn raid controller zijn? Ik kan het met de CLI tool zo niet vinden namelijk.

Kijk net op de site van de fabrikant

Ø Intel 80331 I/O processor
Ø 64-bit/133MHz PCI-X Bus compatible
Ø 128MB on-board DDR333 SDRAM with ECC protection
Ø Write-through or write-back cache support
Ø Support up to 4/8/12/16 Serial ATA drives
Ø Multi-adapter support for large storage requirement
Ø BIOS boot support for greater fault tolerance
Ø BIOS PnP (plug and play) and BBS (BIOS boot specification) support
Ø Areca polynomial ASIC to support extreme performance RAID 6 function
Ø NVRAM for RAID event & transaction log

(Bron: http://www.areca.com.tw/products/html/pcix-sata.htm)
Wat wil je er mee zeggen kees?
Ik durf zo niet te zeggen waar het op staat.

EDIT: Write-back staat aan zie ik net

[ Voor 81% gewijzigd door Snow_King op 25-01-2005 10:28 ]

[Snow_King]

Toch een kickje.

Deze server dient dus als een fileserver voor een webcluster en draait NFS.

Kan het zijn dat NFS gewoon bagger is met presteren met kleine files?

[Jelmer]

Yup, heb vandaag een kleine testjes gedaan met bonnie++ via NFS over gigabit tussen 2 dual xeon 3GHz met 36GB scsi schijven. Bij mij waren ook alle nfsd's voorzien van een status D. Niet verwonderlijk eigenlijk, want ze wachten op de harddisk(s) welke gewoon (te) traag zijn. Daarnaast is NFS ook niet echt lief (zeker niet met erg veel en kleine files..)

Als je er interesse in hebt kan ik morgen de bonnie++ resultaten wel even posten.

Heb overigens gebruik gemaakt van ext3, ga ook nog eens xfs proberen (mits nfs het ondersteund, anders reiser)

[ Voor 24% gewijzigd door Jelmer op 27-01-2005 23:07 ]

[Snow_King]

Ik draai op een stripe-size van 128K, zou het heel veel uitmaken als ik deze terug zet naar bijv 16K of 8K? Het is een webcluster, dus vooral echt kleine files.

Ik kan het niet vinden in de docu van de controller, maar kan je mét databehoud de stripe-size wijzigen?

[Verwijderd]

Staat NFS file locking uit?

[Kees]

Probeer op de raid controller te kijken of write-back aanstaat (en of je een batterij hebt )
dat scheelt nogal in performance op de langere termijn (als in; de eerste gig gaat prima, daarna wordt het erg traag)
write-back loste dat probleem bij mij iig op

[Sendy]

Als je hdparm op een gemounte harddisk draait, dan zijn IMHO de resultaten niet betrouwbaar.

[Snow_King]

Kees schreef op vrijdag 28 januari 2005 @ 00:18:
Probeer op de raid controller te kijken of write-back aanstaat (en of je een batterij hebt )
dat scheelt nogal in performance op de langere termijn (als in; de eerste gig gaat prima, daarna wordt het erg traag)
write-back loste dat probleem bij mij iig op

Staat aan.

Op die array staat zo'n 300GB aan data.

Met file locking doel je op de nolock optie bij het mounten op de nfs clients?

[ Voor 10% gewijzigd door Snow_King op 28-01-2005 03:41 ]

[lvh]

Is dit terwijl hij gemount is? Manpage van hdparm zou moeten aangeven dat je het enkel correct kan doen als hij niet gemount is.

[Snow_King]

Ik heb de stripe-size van de array van 128k naar 16k gezet en de firmware ge-update, maar alsnog status D.

Heeft iemand een idee?