Systeem vertraagt ontzettend bij veel disk io

[zzattack]

Mijn Debian lenny systeem heeft een vervelend probleem: het wordt ontzettend traag zodra er veel disk I/O is. Wanneer ik bijvoorbeeld 3 of meer RAR archieven uitpak is de apache server al snel niet meer te bereiken. De server deelt ook de internetverbinding, ik gebruik hier geen 'normale' router voor omdat die van ons niet genoeg throughput heeft. De box draait ook een DHCP server. Nu is het zeer tijdelijke niet bereikbaar zijn van de http server niet zo'n ramp, maar het is wel ontzettend vervelend dat zelfs clients die een ip van de DHCP server hebben gehad deze verliezen (in Windows krijgen ze dan "limited connectivity" ofzo). Internet is op geen enkele pc in het lan meer te gebruiken, onderling pingen en lokale verbindingen werken nog wel.

De HDD die ik gebruik is http://tweakers.net/price...nt-f1-dt-hd103uj-1tb.html, volgens hdparm is hij niet heel erg traag.

code:

 Timing cached reads:   2068 MB in  2.00 seconds = 1033.84 MB/sec
 Timing buffered disk reads:  240 MB in  3.01 seconds =  79.84 MB/sec

De processor is niet top, een AMD Athlon 5200+, er zit 4gb RAM in en ik draai de redelijke recente kernel 2.6.28-3. De lenny release staat gepland voor morgen dus ik neem niet aan dat er nog veel unstable packages tussen zitten. Ik heb hier een vmstat logje gemaakt, http://zzattack.org/vmstat.log, de eerste paar seconden is onder normale omstandigheden, na een paar seconde begin ik te unrarren.

Mijn vraag is nu wat hier aan te doen valt, of hoe ik er beter achter kan komen wat er fout gaat? Alvast erg bedankt.

[AlexanderB]

unrarren is heel zwaar voor de cpu? als je dan ook nog ns 3 archives tegelijk doet (bijna gegarandeerd 100% full load) dan blijft dr idd niets over voor de rest van de functies van de machine..

[zzattack]

Volgens mij is unrarren niet bepaald zwaar voor de CPU maar juist wel voor de disk. Het zijn ook gewoon archieven zonder echte compressie, meer bedoeld om grote files in meerdere delen op te splitsen.

Enig idee wat er aan te doen valt?

[Arnout]

AlexanderB schreef op vrijdag 13 februari 2009 @ 16:21:
unrarren is heel zwaar voor de cpu? als je dan ook nog ns 3 archives tegelijk doet (bijna gegarandeerd 100% full load) dan blijft dr idd niets over voor de rest van de functies van de machine..

Dat is niet waar. Als ik 3 tarballs tegelijk uitpak dan blijft de rest prima werken. Ik heb nog nooit meegemaakt dat internet delen (NAT) trager ging of uitviel door een hoge load op server.

Waar komen die rar's vandaan? Over het netwerk?

[heuveltje]

Arnout schreef op vrijdag 13 februari 2009 @ 16:34:
[...]

Dat is niet waar. Als ik 3 tarballs tegelijk uitpak dan blijft de rest prima werken. Ik heb nog nooit meegemaakt dat internet delen (NAT) trager ging of uitviel door een hoge load op server.

Waar komen die rar's vandaan? Over het netwerk?

Tar en Rar zijn niet hetzelfde
Bij Rar op het zwaarste compressie niveau moet er door de pc behoorlijk gerekend worden
Als je er dan ook nog 3 tegelijkertijd doet, dan zal dat zeker een behoorlijke load veroorzaken.


Maar "limited connectivity" staat in windows idd voor wel netwerk, maar geen ip adres.
Dan moet je je lease time wel extreem laag zijn wil je daar last van gaan hebben.
Danwel je mount op 1 of andere manier die rar's van het netwerk. als er dan idd zo'n berg data overgaat kun je een 100mbit lijn makkelijk volkrijgen, en dan kom je ook in de problemen

Overigens lijkt me dat je in NoS hier een stuk meer hulp zult kunnen vinden. Dit lijkt me meer aan het OS te liggen dan aan de HD .

[ Voor 15% gewijzigd door heuveltje op 13-02-2009 16:55 ]

[nose]

Heb je al eens via mpstat of top gekeken hoeveel tijd je cpu in de wait state spendeert? Lijkt er namelijk erg op dat dit het geval is.
Ik vermoed nml dat je een vrij grote partitie (tegen de TB ?) in ext3 hebt staan? Als je daar veel op gaat schrijven is dat nogal cpu intensief. Daarnaast vind ext3 hele grote partities niet zo fijn. Bij ext2 is de cpu belasting dan weer een stuk lager. Ext4 (persoonlijk nog geen ervaring mee) is dan juist weer voor grote partities interessant, die kan daar een stuk beter mee om gaan. Cpu belasting heb ik nog niks over kunnen vinden.
Ik zit zelf nml met een soortgelijk probleem en kwam tijdens mijn speurtochten onderandere dit plaatje tegen:

[zzattack]

nose schreef op vrijdag 13 februari 2009 @ 22:57:
Heb je al eens via mpstat of top gekeken hoeveel tijd je cpu in de wait state spendeert? Lijkt er namelijk erg op dat dit het geval is.
Ik vermoed nml dat je een vrij grote partitie (tegen de TB ?) in ext3 hebt staan? Als je daar veel op gaat schrijven is dat nogal cpu intensief. Daarnaast vind ext3 hele grote partities niet zo fijn. Bij ext2 is de cpu belasting dan weer een stuk lager. Ext4 (persoonlijk nog geen ervaring mee) is dan juist weer voor grote partities interessant, die kan daar een stuk beter mee om gaan. Cpu belasting heb ik nog niks over kunnen vinden.
Ik zit zelf nml met een soortgelijk probleem en kwam tijdens mijn speurtochten onderandere dit plaatje tegen:
[afbeelding]

Volgens de vmstat log die ik had bijgevoegd wacht de CPU inderdaad erg veel op de disk. Wat je zegt over de grote partitie in ext3, klopt helemaal. Erg interessant plaatje ook, ik zal m'n ext3 partitie eens als ext4 mounten en kijken of het verschil maakt. Ik neem aan ik hiermee via google een stuk verder kan komen. Bedankt voor alle suggesties!

[RemcoDelft]

Wellicht kan je de kernel-timing in de kernel-config configureren voor "desktop"?
Of gewoon niet tegelijk unrarren maar na elkaar: unrar x file1.rar; unrar x file2.rar enz.
Of "nice" er voor, wil ook nog wel eens schelen

[TERW_DAN]

Titelchangeje