dwarsliggende kerneldeamons (kernel 2.4.18)

[iGadget]

Op mijn eigen bak freezed kupdated m'n hele machine als ik een tijdje aan het kopieëren ben geweest. Soms hangt m'n bak langer dan een minuut voordat het kopieren verder gaat. In de tussentijd staat de klok stil, ik kan m'n muis niet bewegen en de load loopt op tot boven de 20.

Iemand enig id hoe ik ofwel kupdated kill, ofwel er achter kom waarom 'ie de boel zo loopt te verneuken?

Verder loopt op onze fileserver kswapd af en toe de boel een paar seconden te hangen zodra ik naar die machine iets toe kopieër. Bij lezen vanaf die machine gebeurt dit niet.

Ik heb beide processen al ge-reniced naar 19 (was 0) maar dit maakt niets uit.

Hoe los ik dit op?

Beide machines draaien debian met kernel 2.4.18.

[Jelmer]

Wat voor een architectuur hebben beide pc's? (CPU, chipset, geheugen, disks+controler, uitbreidingskaarten, etc)

[iGadget]

Mijn eigen machine (doet moeilijk met kupdated):
-MSI K7N420Pro Mobo (nVidia nForce chipset, nvidia driver geinstalleerd)
-Athlon XP 1700+
-1GB DDR
-ATI Radeon 8500
-2x Promise Ultra100 TX2 IDE kaartjes (hangen nog geen schijven aan)
-Dynalink FireWire kaartje (VIA chipset)

Runt Debian Unstable/Sid

Onze fileserver (doet moeilijk met kswapd):
-MSI BX Master (Intel BX chipset)
-P3-500
-384MB SDRAM
-standaard grafisch kaartje, SiS geval
-3Ware Escalade 7810 IDE RAID kaart met daaraan 8 schijven in RAID5 modus
-3x Intel EePro100 ethernetkaart getrunkt tot 1x 300mbit
-Dec/Tulip 10/100 ethernetkaart (DECchip 21140 chipset)

Runt Debian Testing/Woody

[iGadget]

Anyone?

[deadinspace]

Op donderdag 06 juni 2002 20:32 schreef iGadget het volgende:
Anyone?

Het is hier niet de bedoeling dat je na een uur al je topic kickt. Veel mensen zijn hier niet de hele dag en lezen je topic dus pas later.
Als er 24 uur lang niet gereplied is in je topic mag je hem een hengst geven.

Ontopic:
kupdated en kswapd zijn, zoals je zelf al zegt, kerneldaemons. Kerneldaemons killen heeft meestal niet zo bijzonder goede effecten op de werking van je systeem

kswapd is (duh) voor het swappen, en kupdated is de ext3-bijwerk-daemon. Beiden doen dus iets met je HD...
Als je computer 'freezed', is je HD dan druk bezig?
Staat dma aan op je HD?
Staat er iets in /var/log/messages over je HD?

[_JGC_]

Kupdated is niet zo moeilijk, ff googlen, dan ff paar klikken verder in die thread:
http://www.uwsg.iu.edu/hypermail/linux/kernel/0202.2/0549.html
Verkeerde driver voor je IDE controller, en ik denk dat dat idd niet zo vreemd is voor een nforce

Kswapd doet je swappen, je beschrijft niet precies wat je probleem ermee is, dus kan ik je ook niet helpen met zoeken in google

[iGadget]

Sorry mensen... was niet m'n bedoeling om iemand te irriteren.

Je kent het gevoel vast wel... je bent de hele dag (wat zeg ik, al meerdere dagen) bezig om alles werkend te krijgen, en dan loop je tegen zo'n probleem aan. Geduld is een schone zaak, maar niet 1 van m'n sterkste kanten

Anyway, wat die kswapd betreft - ik vermoed dat die roet in het eten gooit bij de writeperformance van onze fileserver. Als ik met 'top' de systeemprocessen in de gaten hou, en ik ga lopen kopieren naar die machine toe, dan gaat dat een tijdlang goed. Op een gegeven moment 'freezed' de connectie echter even, er wordt geen data meer geschreven, en precies op dat moment staat kswapd even bovenaan bij top. Zodra kswapd klaar is met whatever 'ie aan het doen was, gaat de write-actie weer verder. Dit proces herhaalt zich voortdurend.

Wat ik vermoedde was dat er op dat moment gewoon geswapped werd door kswapd (waar is een swap deamon voor alsie niet swapt zeg maar). Aangezien er 384MB in die bak zit, en hij behalve files serven verder niets hoeft te doen, dacht ik slim te zijn door 'swapoff /dev/[swapdrive]' te doen, in de hoop dat kswapd het dan wel zou laten om te swappen. Helaas lostte dit niets op. Vandaar dat ik kswapd graag zou willen disablen op de 1 of andere manier, gewoon om te kijken of de write performance dan beter wordt.

Het gekke is dus wel dat dit bij lezen totaal niet speelt, dit gaat gewoon met de volle 300mbit, zonder schokken.

Vette pech dus voor mij wat betreft die kupdated, ik draai inderdaad ext3, en de chipset van de nforce is zo unknown als het maar kan. Zou Reiserfs of XFS hier misschien een betere oplossing zijn?

[Verwijderd]

Op vrijdag 07 juni 2002 00:26 schreef iGadget het volgende:
Zou Reiserfs of XFS hier misschien een betere oplossing zijn?

Ik zou de gok met XFS best wel eens wagen. Ik merk op mijn eigen machinetjes dat XFS toch efficienter werkt dan ext3, alhoewel ik lang niet zo erge problemen heb als jij (af en toe schokt het eventjes (als iets druk bezig is), voor de rest werkt alles perfect). Op mijn XFS machine heb ik daar geen last van. Echter, op mjn XFS machine is alles, zowel hardwarematig als softwarematig, aangepast om geen IDE/PCI interferentie timeouts te hebben...

Als eerste dus maar eens de HD onderzoeken, en gelijk maar je moederbord. Op de kupdated machine (die athlon): staat DMA aan (hdparm -d)? Welke chipsetdriver gebruik je in je kernel voor je moederbord (of gewoon de default?)? Op de kswapd machine (die BX geval): is dat een 440BX? Ook hier, staat DMA aan op de HD?

Overigens gebruik je nu overal IDE en heb je overal add-on IDE kaartjes hangen, zou SCSI niet handiger zijn? IDE is nou niet bepaald een elegant iets, om maar niet gewoon te zeggen dat IDE eigenlijk best zwaar klote is (i.e. voor de gemiddelde gebruiker meer dan voldoende, maar voor degene die meer dan gemiddelde performance nodig heeft of zwaardere eisen stelt is SCSI vaak beter). Neem ook mee dat IDE dus wel load veroorzaakt en SCSI niet omdat SCSI zijn eigen bus heeft en IDE via de mainboard bus gaat (oftewel, IDE/PCI interference bestaat wel, SCSI/PCI niet).

[Onno]

Op vrijdag 07 juni 2002 07:30 schreef beelzebubu het volgende:
Neem ook mee dat IDE dus wel load veroorzaakt en SCSI niet omdat SCSI zijn eigen bus heeft en IDE via de mainboard bus gaat (oftewel, IDE/PCI interference bestaat wel, SCSI/PCI niet).

Dat gaat natuurlijk alleen op als je het over transfers tussen twee SCSI/IDE apparaten onderling hebt. Als je gewoon data leest/schrijft belast SCSI je PCI bus net zo hard, en kost IDE niks meer cpu tijd. (als je DMA gebruikt)

[Jelmer]

Op vrijdag 07 juni 2002 07:30 schreef beelzebubu het volgende:

[..]

Overigens gebruik je nu overal IDE en heb je overal add-on IDE kaartjes hangen, zou SCSI niet handiger zijn? IDE is nou niet bepaald een elegant iets, om maar niet gewoon te zeggen dat IDE eigenlijk best zwaar klote is (i.e. voor de gemiddelde gebruiker meer dan voldoende, maar voor degene die meer dan gemiddelde performance nodig heeft of zwaardere eisen stelt is SCSI vaak beter). Neem ook mee dat IDE dus wel load veroorzaakt en SCSI niet omdat SCSI zijn eigen bus heeft en IDE via de mainboard bus gaat (oftewel, IDE/PCI interference bestaat wel, SCSI/PCI niet).

Uhm, dit gaat dan alleen op voor zijn nForce machine, want zoals je kunt lezen heeft hij een 3ware escalade raid controler. Zoals je weet heft dat ding gewoon een scsi interface naar de pc toe.

Verder heb ik het idee dat het gaat om de write-buffer. Ikzelf zat pas op een LAN en er was iemand vrolijk aan het uppen en zo nu en dan hing het hele systeem even doordat de write-buffer (niet die van de schijf dus) werd leeg gemaakt en de schijf een seconde of 4 flink druk was.

Of dit ook het geval is met andere FS'en ga ik nog even uitzoeken.