[Linux] Veel iowait.

[Keiichi]

Op mijn server ben ik eenvoudige benchmarkjes aan het draaien:

code:

root@s001a:/images# dd if=/dev/zero of=20070907-1.img bs=1024k count=20480
20480+0 records in
20480+0 records out
21474836480 bytes (21 GB) copied, 347.056 s, 61.9 MB/s

Tijdens dit gebeuren reageert het systeem zeer zeer traag. In 'top' zie ik dat iowait voor 1 proc om 100% staat en de load gaat richting 12

Dit is enigszins absurd voor een wat ik denk eenvouding IO actie.

Paar handige gegevens:

Xeon E5335 servertje
8gig ram
3ware 9550-SXU-4LP raid adapter
Linux kernel: 2.6.18-xen

Om niet blind te staren op de kernel versie, heeft de stock kernel van slackware 2.6.22.1 er evenveel last van.

Waaraan kan dit liggen?

[dragunova]

wat wil je hiermee precies testen?

[ Voor 69% gewijzigd door dragunova op 07-09-2007 22:33 ]

[rvanlooijen]

Vrij veel load bij kopieren lijkt me vrij logisch,
je wilt toch immers dat het zo snel mogelijk gebeurt?

Je zou er eventueel natuurlijk wel nice voor kunnen typen,
maar dat zal je weer niet het mooiste benchmark resultaat laten zien.

[Gomez12]

Wat wil jij benchmarken??? Hoe snel je systeem is als het niets doet???

Beetje benchmark hoort volgens mij zoveel mogelijk uit je systeem te halen waardoor het inderdaad traag wordt.

[deadinspace]

dragunova schreef op vrijdag 07 september 2007 @ 22:30:
wat wil je hiermee precies testen?

Caesartje schreef op vrijdag 07 september 2007 @ 22:31:
... maar dat zal je weer niet het mooiste benchmark resultaat laten zien.

Gomez12 schreef op vrijdag 07 september 2007 @ 22:53:
Wat wil jij benchmarken??? Hoe snel je systeem is als het niets doet???

Wat trekken jullie allemaal vlug conclusies? Als je niet weet waarom de TS iets doet, dan kun je dat natuurlijk ook gewoon vragen.

En de filename die de TS gebruikt suggereert dat het hier helemaal niet om een benchmark gaat (maar bijvoorbeeld om disk images voor virtualisatie).

Los daarvan hoort zo'n activiteit geen load van 12 en een zeer traag reagerend systeem tot gevolg te hebben.

---

Wat betreft het probleem zelf, zulk soort taferelen doen mij altijd denken aan een disk controller die PIO gebruikt in plaats van DMA, of aan een Via chipset. Maar PIO lijkt me in dit geval een beetje sterk gezien de throughput van 70 MB/sec, en in zo'n systeem zal wel geen Via chipset zitten (toch?).

Kun je misschien wat diagnostics doen op je 3ware (driver)? Staat er tijdens het dd'en wat interessants in je /var/log/messages? Hoeveel disks hangen er trouwens aan je controller, en in wat voor configuratie?

[dragunova]

deadinspace schreef op vrijdag 07 september 2007 @ 23:14:

Wat trekken jullie allemaal vlug conclusies? Als je niet weet waarom de TS iets doet, dan kun je dat natuurlijk ook gewoon vragen.

Ik weet niet of ik nu heel erg n00bish ga klinken, maar ik weet echt niet wat de TS nu wil testen, daarom vraag ik het hem ja.


quote:
dragunova schreef op vrijdag 07 september 2007 @ 22:30:
wat wil je hiermee precies testen?


Ik trek even geen conclusie hoor. Volgens mij doe jij dat zelf met je conclusie dat het te maken heeft met een controller.

De TS test namelijk met een file uit /dev/zero. Dat is niet iets wat op hdd staat.

Daarom de vraag wat TS nu wil testen, want de hdd of daaraan gekoppelde controller test TS niet hiermee.

[ Voor 37% gewijzigd door dragunova op 07-09-2007 23:58 ]

[dragunova]

mijn eerste reactie was overigens ook "heb je dma wel aan staan?"
Totdat ik de hele post van TS las.

[deadinspace]

dragunova schreef op vrijdag 07 september 2007 @ 23:52:
Ik weet niet of ik nu heel erg n00bish ga klinken, maar ik weet echt niet wat de TS nu wil testen, daarom vraag ik het hem ja.

Ok, sorry, dan heb ik dat verkeerd geinterpreteerd; het kwam op mij over alsof je het zinloos vond.

Het was overigens niet persoonlijk bedoeld, maar het leek gewoon een beetje alsof iedereen maar aannam dat de TS wat aan het benchen was en zich afvroeg wat hij hier nou kwam zeuren

Volgens mij doe jij dat zelf met je conclusie dat het te maken heeft met een controller. De TS test namelijk met een file uit /dev/zero. Dat is niet iets wat op hdd staat.

De TS kopieert 21GB van /dev/zero naar een file (naar /images/20070907-1.img om precies te zijn). En die file staat op zijn disk(s) aan zijn 3ware controller nemen we maar even aan.

Het is vrij veilig om aan te nemen dat 21GB lezen van /dev/zero niet voor de load/traagheid zorgt; Het schrijven van 21GB naar zijn disk(s) is een veel waarschijnlijker kandidaat

Daarom de vraag wat TS nu wil testen, want de hdd of daaraan gekoppelde controller test TS niet hiermee.

Dat klopt dus niet. Bovendien suggereert de gebruikte filename (/images/20070907-1.img) dat het niet gaat om een test, maar om het maken van een lege image file voor het een of ander (zoals disk images voor virtualisatie).

[Verwijderd]

Ik weet niet of er nog speciale magie in /dev/zero zit, maar als het hetzelfde werkt als /dev/random, dan zal de CPU elke nul afzonderlijk aan de harddisk geven. Hoe sneller de harddisk dan schrijft, hoe meer de CPU moet doen. Als je tussen 2 schijven kopieert, dan lijkt het me dat DMA ervoor zorgt dat je CPU andere dingen kan gaan doen.

[Keiichi]

het gaat idd om een image voor virtualisatie. Maar dezelfde methode gebruik ik ook voor een quick en dirty test van de snelheid van het filesystem, maar dit heeft nooit zo'n probleem gegeven

Er hangen 4 WD harde schijven aan van 500gig (WD5000ABYS)

Tijdens dd worden er geen bericht afgegeven door de 3ware driver. Het enige wat tijdens de kernel boot gegeven word is:

SCSI subsystem initialized
3ware 9000 Storage Controller device driver for Linux v2.26.02.007.
ACPI: PCI Interrupt 0000:09:01.0[A] -> GSI 16 (level, low) -> IRQ 16
3w-9xxx: scsi0: AEN: INFO (0x04:0x0053): Battery capacity test is overdue:.
scsi0 : 3ware 9000 Storage Controller
3w-9xxx: scsi0: Found a 3ware 9000 Storage Controller at 0xda300000, IRQ: 16.
3w-9xxx: scsi0: Firmware FE9X 3.04.00.005, BIOS BE9X 3.04.00.002, Ports: 4.
Vendor: AMCC Model: 9550SXU-4L DISK Rev: 3.04
Type: Direct-Access ANSI SCSI revision: 03
SCSI device sda: 2929625088 512-byte hdwr sectors (1499968 MB)
sda: Write Protect is off
sda: Mode Sense: 23 00 00 00
SCSI device sda: drive cache: write back, no read (daft)
SCSI device sda: 2929625088 512-byte hdwr sectors (1499968 MB)
sda: Write Protect is off
sda: Mode Sense: 23 00 00 00
SCSI device sda: drive cache: write back, no read (daft)
sda: sda1 sda2
sd 0:0:0:0: Attached scsi disk sda
sd 0:0:0:0: Attached scsi generic sg0 type 0
st: Version 20050830, fixed bufsize 32768, s/g segs 256

Wat me op het eerste gezicht gewoon normaal lijkt.

@deadinspace. Ik ga eens even rondneuzen of ik hier iets van kan vinden.

[dragunova]

als jij idd uit /dev/zero schrijft naar een bestand zal je cpu (zoals DOT ook al zei) zover belast worden als je hdd's kunnen wegschrijven. Omdat -voor zover ik kan nagaan- output uit /dev/zero volledig door de cpu wordt gegenereerd.

[Verwijderd]

Ik kan aannemen dat de CPU de data voor /dev/zero genereert en dat dit dus extra load met zich meebrengt, maar ik zou toch denken dat een Xeon E5335 met twee vingers in de neus 70MB/s aan nullen kan produceren? Dus ik geef de TS gelijk: dat systeem mag nooit zo traag reageren!

[edit]
Ik heb net ff dezelfde test gedaan uit nieuwsgierigheid. Resultaat:

code:

piranha@shuttle:~# dd if=/dev/zero of=20070907-1.img bs=1024k count=20480
20480+0 records in
20480+0 records out
21474836480 bytes (21 GB) copied, 263.339 seconds, 81.5 MB/s

en ondertussen gewoon verder gewerkt zonder er eigenlijk iets noemenswaardig van te merken. De load gaat richting 10 hier, dd gebruikt zo'n 30% CPU. En dat op een dual dualcore Opteron 270 met 4 GB RAM, en 4x WD2500KS (250 GB dus) in raid 5 op een Areca ARC-1210 controller. Linux 2.6.21.1 SMP PREEMPT. Dus ja, er is iets mis met je systeem maar ik zou niet weten wat. Misschien even proberen met een recentere kernel ofzo?_{lezen visje, lezen...}

[ Voor 57% gewijzigd door Verwijderd op 08-09-2007 13:24 ]

[deadinspace]

Verwijderd schreef op zaterdag 08 september 2007 @ 03:33:
Ik weet niet of er nog speciale magie in /dev/zero zit, maar als het hetzelfde werkt als /dev/random, dan zal de CPU elke nul afzonderlijk aan de harddisk geven. Hoe sneller de harddisk dan schrijft, hoe meer de CPU moet doen.

dragunova schreef op zaterdag 08 september 2007 @ 11:56:
als jij idd uit /dev/zero schrijft naar een bestand zal je cpu (zoals DOT ook al zei) zover belast worden als je hdd's kunnen wegschrijven. Omdat -voor zover ik kan nagaan- output uit /dev/zero volledig door de cpu wordt gegenereerd.

/dev/zero is echt het probleem niet hoor

De code voor /dev/zero en /dev/null is geoptimaliseerd om zo weinig mogelijk werk te hoeven te doen. Onder normaal gebruik van /dev/zero schrijft de kernel helemaal geen nullen weg maar gebruikt leuke vm truukjes:

$ dd if=/dev/zero of=/dev/null bs=1M count=20480
20480+0 records in
20480+0 records out
21474836480 bytes (21 GB) copied, 0.370561 seconds, 58.0 GB/s

Ziedaar, mijn miezerige Athlon XP kopieert 58 GB/sec

Keiichi schreef op zaterdag 08 september 2007 @ 11:22:
het gaat idd om een image voor virtualisatie. Maar dezelfde methode gebruik ik ook voor een quick en dirty test van de snelheid van het filesystem, maar dit heeft nooit zo'n probleem gegeven

Ik heb het ook eens geprobeerd op mijn desktop, en mijn systeem werd er ook knap traag van. Toen herinnerde ik me dat ze rond 2.6.18 de default I/O scheduler van anticipatory naar cfq hadden veranderd, en dat ik dat toen ook al vervelend vond. Nogmaals getest maar dan met anticipatory, en toen was het een stuk draaglijker.

Dus, doe eens

echo anticipatory > /sys/block/sda/queue/scheduler

en probeer het nog eens?

noatime zou trouwens ook kunnen helpen, maar of dat een optie is hangt een beetje af van welke programma's je gebruikt; sommige programma's (bv mutt) werken niet zo goed zonder atime.

[Keiichi]

Verwijderd schreef op zaterdag 08 september 2007 @ 13:04:
Ik kan aannemen dat de CPU de data voor /dev/zero genereert en dat dit dus extra load met zich meebrengt, maar ik zou toch denken dat een Xeon E5335 met twee vingers in de neus 70MB/s aan nullen kan produceren? Dus ik geef de TS gelijk: dat systeem mag nooit zo traag reageren!

[edit]
Ik heb net ff dezelfde test gedaan uit nieuwsgierigheid. Resultaat:

code:

piranha@shuttle:~# dd if=/dev/zero of=20070907-1.img bs=1024k count=20480
20480+0 records in
20480+0 records out
21474836480 bytes (21 GB) copied, 263.339 seconds, 81.5 MB/s

en ondertussen gewoon verder gewerkt zonder er eigenlijk iets noemenswaardig van te merken. De load gaat richting 10 hier, dd gebruikt zo'n 30% CPU. En dat op een dual dualcore Opteron 270 met 4 GB RAM, en 4x WD2500KS (250 GB dus) in raid 5 op een Areca ARC-1210 controller. Linux 2.6.21.1 SMP PREEMPT. Dus ja, er is iets mis met je systeem maar ik zou niet weten wat. Misschien even proberen met een recentere kernel ofzo?_{lezen visje, lezen...}

Zou je dit voor mij nog eens kunnen doen en ondertussen "vmstat 2" kunnen draaien en hier kunnen posten?

Een load van 10 is niet normaal. Mijn load gaat ook die richting ongeveer op.

[igmar]

't is denk ik een scheduler probleem. Deze machine (lees : laptop) trekt 24 MB/sec, en dan staat de load zo rond de 20 - 25%, en zit ik te browsen en naar hotradio plus te luisteren. Ik heb alleen wel de CFS scheduler patches geinstalleerd
Een andere mogelijke kandidaat is de RAID controller, maar ik zou eens beginnen met Ingo Molnar's CFS patches, en dan het nog een keer proberen.

[Keiichi]

igmar schreef op maandag 01 oktober 2007 @ 10:32:
't is denk ik een scheduler probleem. Deze machine (lees : laptop) trekt 24 MB/sec, en dan staat de load zo rond de 20 - 25%, en zit ik te browsen en naar hotradio plus te luisteren. Ik heb alleen wel de CFS scheduler patches geinstalleerd
Een andere mogelijke kandidaat is de RAID controller, maar ik zou eens beginnen met Ingo Molnar's CFS patches, en dan het nog een keer proberen.

Ik draai 2.6.23-rc8 nu volgens mij zaten die daar al in.. toch?

Heb 20-25% load op SYS of IOWAIT staan? Sys is wel normaal bij zulke acties.

[deadinspace]

Heb je de suggestie in mijn post van drie weken geleden al geprobeerd?

[Keiichi]

deadinspace schreef op maandag 01 oktober 2007 @ 14:24:
Heb je de suggestie in mijn post van drie weken geleden al geprobeerd?

Yep, allang, maar heeft niet geholpen.

Ik heb ook testen gedaan waarbij ik geen enkel gebruik van een FS maak (Door bv dd if=/dev/zero of=/deb/sdb1) en er gebeurd exact hetzelfde.

[Keiichi]

Ik heb trouwens misschien een soort van idee gekregen hierover.

De kaart bevat 128Mbytes aan cache geheugen. Als ik 'time ls -l' doe (op een plek op het FS waar ie waarschijnlijk nog geen cache geheugen van heeft) dan duurt het ongeveer 2 seconden. Het schrijft met 60Mbytes/sec weg, dus al de opdracht worden doodleuk achter in dat geheugen gepropt en moet wachten tot de rest weg is Ik kan de cache wel uitzetten, maar dan blijft er geen performance meer over

Zou ik met dit gegeven, mocht het kloppen, iets verder kunnen tweaken?