[linux] Volledig systeem stottert elke zoveel tijd

[BezurK]

Hoi, ik heb een vreemd probleem, mijn machientje (slack loopt perfect zonder problemen eigenlijk en als ik die heb dan kan ik ze meestal zelf wel oplossen maar hier kom ik dus totaal _niet_ uit:
Mijn volledige systeem stottert elke 20 minuten voor ongeveer 5 a 10 seconde, in principe niet zo'n probleem maar het word al snel irritant als je een film aan het kijken ben of een lekker potje RtCW speelt.
Nu dacht ik het zelf wel ff op te lossen dus ben ik een beetje opzoek gegaan naar wat het zou kunnen zijn, als eerste heb ik /var/log/messages eens bekeken, en toen vond ik dit:

code:

[...]
Jan 16 18:02:28 rachael -- MARK --
Jan 16 18:22:28 rachael -- MARK --
Jan 16 18:42:28 rachael -- MARK --
Jan 16 19:02:28 rachael -- MARK --
Jan 16 19:22:28 rachael -- MARK --
Jan 16 19:42:28 rachael -- MARK --
Jan 16 20:02:28 rachael -- MARK --
[...]

en dit gaat eigenlijk het hele bestand zo door, precies elke 20 minuten een --mark--, waar komt dit vandaan en waarom is dit? Ik denk namelijk dat op de een of andere manier dit de oorzaak is.

[Arzie]

Lijkt wel system restore

[Jordi]

Da's syslogd die elke 20 minuten een --MARK-- neerzet om aan te geven dat ie 'nog leeft'. Dat een systeem daar 5 tot 10 seconden traag van wordt, is raar. DMA op je harddisk staat aan?

[deadinspace]

Dat is je syslogd, die elke 20 minuten aangeeft dat alles nog leeft. Het interval waarmee hij dat doet is te veranderen... Moet je maar even man syslog of man syslogd doen, staat het vast wel in.
Ik zou het alleen vreemd vinden als dit de oorzaak zou zijn... Tenzij hij een probleem zou hebben met het wegschrijven hiervan (HD kaput, HD vol)...

[Verwijderd]

Op donderdag 17 januari 2002 16:28 schreef Arzie het volgende:
Lijkt wel system restore

"man syslog" zal meer wonderen doen
Zonder te zeggen wat het is; het is niks ernstigs die -- MARK -- messages.

Hmzz, het klinkt alsof er elke 20 minuten een cronjob gestart wordt o.i.d. Overigens is de PREEMPTIBLE kernel patch misschien wel iets voor je. Het aantal hickups wordt dan enorm veel minder (ook onder zware load)

[edit]
Whehe , 3 mensen die hetzelfde zeggen

[Niek]

Even opgezocht:

[topic=168352/1/25]
[topic=303364/1/25]
[topic=281478/1/25]
[topic=209558/1/25]

[Jordi]

Op donderdag 17 januari 2002 16:31 schreef deadinspace het volgende:
Dat is je syslogd, die elke 20 minuten aangeeft dat alles nog leeft.

Ghe... bijna letterlijk
Het was iets met grote gedachten

[Verwijderd]

Hmzz, ik zie nu pas dat die marks ook precies elke keer om de 20 minuten gebeuren.

Das wel vreemd, want daar mag het systeem toch niet echt traag van worden (ook al is syslogd absoluut een trage logdaemon). Zoals gezegd, controleer je hd eens qua snelheid.

[RemcoX]

Op donderdag 17 januari 2002 16:32 schreef The_Surfer het volgende:
Even opgezocht:

[topic=168352/1/25]
[topic=303364/1/25]
[topic=281478/1/25]
[topic=209558/1/25]

Let vooral op die eerste en die derde

[BezurK]

Wow! deadinspace en jotti liggen volledig op 1 lijn

Mijn HD is niet vol (pas 20% vol ofzo) en kapot issie ook niet, althans, niet dat ik weet, ik transfer nog steeds bestandjes met 6 a 7 mb/s constant over het netwerk... Volgens hdparm staat DMA uit voor /dev/hda (waar /var op staat) en ik kan het niet aan zetten want ik heb vorige week ff geformatteerd, waarom weet ik trouwens nog steeds niet , en dus zit ik nog steeds met die standaard 2.4.5 kernel van slack 8.0
Ik heb 2.4.17 net gedownload, die ga ik ff compilen met DMA support en dan ff kijken of het probleem weg is als ik DMA aan zet op hda, iig bedankt voor jullie reacties

[BezurK]

btw, check dit:

code:

root@rachael:/home/willem# hdparm -tT /dev/hda

/dev/hda:
 Timing buffer-cache reads:   128 MB in  0.79 seconds =162.03 MB/sec
 Timing buffered disk reads:  64 MB in 14.10 seconds =  4.54 MB/sec

Hij is redelijk traag maar kapot issie toch niet lijkt me?!

[Verwijderd]

Op donderdag 17 januari 2002 16:42 schreef BezurK het volgende:
btw, check dit:

code:

root@rachael:/home/willem# hdparm -tT /dev/hda

/dev/hda:
 Timing buffer-cache reads:   128 MB in  0.79 seconds =162.03 MB/sec
 Timing buffered disk reads:  64 MB in 14.10 seconds =  4.54 MB/sec

Hij is redelijk traag maar kapot issie toch niet lijkt me?!

Probeer ook een "hdparm -u1 /dev/hda" als je niet een buggy ide-controller hebt.

Zie "man hdparm" voor uitleg erover

[Verwijderd]

er staat nu in je /etc/sysconfig/syslog een regeltje met

code:

SYSLOGD_OPTIONS="-m 20"

verander dit in "-m 0" en daarna een "service syslog restart"
Vanaf dat moment ben je van je --- MARK --- 's af.
Maar kan wel eens handig zijn als je systeem een keertje frozen staat dat je dan ook weet wanneer dit wel is gebeurd.

[BezurK]

Op donderdag 17 januari 2002 16:44 schreef nelske het volgende:

[..]

Probeer ook een "hdparm -u1 /dev/hda" als je niet een buggy ide-controller hebt.

Zie "man hdparm" voor uitleg erover

Ik heb het aan gezet, hij is er overigens niets sneller van geworden...

Enne, de functie van man hoef je me niet meer uit te leggen hoor , toen iemand begon over DMA was dat nml het eerste wa'k deed, man hdparm

[Verwijderd]

Op donderdag 17 januari 2002 16:42 schreef BezurK het volgende:
btw, check dit:

code:

root@rachael:/home/willem# hdparm -tT /dev/hda

/dev/hda:
 Timing buffer-cache reads:   128 MB in  0.79 seconds =162.03 MB/sec
 Timing buffered disk reads:  64 MB in 14.10 seconds =  4.54 MB/sec

Hij is redelijk traag maar kapot issie toch niet lijkt me?!

Nee hoor! (Nog) niet
Begint pas echt irri te worden als je beneden de 100 kB komt
Heb ik wel eens gehad met een maxtor (daar kwam ik toen achter tijdens een tergend trage fsck)
Winkel heeft 'm toen netjes omgeruild.

[Verwijderd]

Je systeem wordt er ook niet sneller van
Lees maar na in het betreffende stukje. Het verhoogt de responsiveness. Iets wat bij het simultaan draaien van meerdere processen dus goed van pas komt

[deadinspace]

Op donderdag 17 januari 2002 16:33 schreef Jotti het volgende:
Ghe... bijna letterlijk
Het was iets met grote gedachten

Niks! Je hebt gewoon mijn post gelezen en dan zelf gepost en de datum en positie aangepast

Op donderdag 17 januari 2002 16:34 schreef nelske het volgende:
Zoals gezegd, controleer je hd eens qua snelheid.

Mja, hij kan (blijkbaar) wel film kijken, en voor een divx moet hij toch ongeveer 150 kb/s sustained van de schijf lezen, en dat zou dan geen problemen veroorzaken?

Draai anders eens top en kijk wat er allemaal draait op het moment dat hij schokt (of doe 'ps auxf > blaatfile').
Is het trouwens een korte stotter of hakkelt hij wat langere tijd? Doet je HD veel, weinig of niks als hij het doet?

[BezurK]

Het stotteren duurt ongeveer 5 a 6 seconde schat ik, en de HD doet dan helemaal niets, het is denk ik een proces wat op de ene of andere manier elke zoveel tijd (ik gok ongeveer 20min) heel veel CPU vraagt.
Het lullige is dat ik het alleen merk als ik iets CPU intensiefs aan het doen ben zoals gamen of een divx'je kijken, dat zorgt toch gauw voor een cpu-usage van 60-70% en gamen is voluit 100%...

Niemand enig idee? Hij doet het bij mij op een kale installatie van slackware 8.0 ook, dus misschien dat er iemand anders is die dit ook heeft aangezien er best veel mensen slackware draaien hier...

[igmar]

Op donderdag 17 januari 2002 20:33 schreef BezurK het volgende:
Het stotteren duurt ongeveer 5 a 6 seconde schat ik, en de HD doet dan helemaal niets, het is denk ik een proces wat op de ene of andere manier elke zoveel tijd (ik gok ongeveer 20min) heel veel CPU vraagt.
Het lullige is dat ik het alleen merk als ik iets CPU intensiefs aan het doen ben zoals gamen of een divx'je kijken, dat zorgt toch gauw voor een cpu-usage van 60-70% en gamen is voluit 100%...

a) Welke kernel (oude 2.4.x kernels hebben een rotte VM)
b) wat zegt top als ie zo druk is ??

[Verwijderd]

Het probleem had ik ook met SLackware 8.0 en nieuwere kernels. Toevallig ook ReiserFS als / filesystem ? Met ext3 was het niet echt over, met Gentoo en ext2 wel, zonder de genoemde patches. Ik denk toch dat dit Slackware specifiek is. De performance problemen zaten bij mij met name in kernels 2.4.14/15/16/17. Een console onder X was erg traag, mc was niet vooruit te branden etc. En op een bx-133 p3 1000 met 512 MB verwacht je dergelijke vertragingen niet.

[Mior]

Ik heb het ook op mijn workstation.

Ik ben echt dagen bezig geweest om uit te vogelen wat er aan de hand was, en na een tijdje zag ik dat het programma 'kupdated' bovenaan in top staat met 54% cpu load op een 1.4GHz, net voordat het 'hangen' begint (top hangt daarnaa ook).

Het programma killen gaat niet. En ik kan ook nergens wat over het probleem vinden (google, GoT, slackware forum).

[Verwijderd]

Check ff je swap space. Hoeveel is er nog vrij?

ff lekker moeilijk (voor aantal procentjes):

code:

cat /proc/swaps | grep -v File | awk '{print $4" * 100 / "$3}' | bc

Als je performance problemen hebt ALTIJD ff naar je swap kijken.

Als je zo'n nieuwe (grote) harddisk hebt ligt het waarschijnlijk aan de aansturing ervan.

Probeer dan dit:

code:

hdparm -A 1 -c 3 -d 1 /dev/hdx

Waar hdx je harddisk is. hda voor de 1e IDE harddisk, hdb voor de 2e etc.

[zwik]

Laat ik hier nou toch ook last van hebben met m'n Slackware configuratie. Als je er normaal mee werkt heb je er niet zoveel last van inderdaad, maar zodra je een potje Unreal Tournament gaat spelen (of enig ander spel ) dan begint ie soms wel eens te stotteren.

Jammer trouwens dat het Slackware forum down is .

[flat]

Op donderdag 17 januari 2002 16:33 schreef Jotti het volgende:
[...]
Het was iets met grote gedachten

"great minds think alike"