Vastlopers, halve vastlopers en andere vage dingen

[jep]

*Zucht*, ik heb er genoeg van.

Ik beheer een paar RedHat servers, ik weet niet of dit probleem aan RedHat ligt maar toch.

Probleem!:

Processen krijgen soms de D status, gevolg is dat als je iets doet wat met dit proces te maken heeft de load omhoog schiet en da's niet fijn .

Voorbeeld: NFS. Ik weet nu niet meer of NFS zo stinkt of dat er iets anders vreselijk brak is maar ik mount dus elke nacht een NFS volume. Bijna altijd gaat dit goed maar nu tik ik vanmorgen bijvoorbeeld df -h en komt hij niet tot dat volume.. en toen was de load 1 . Als ik vervolgens niet oplet gaan er meer dingen naar D omdat die weer van df gebruik maken . Dit was RedHat 7.0 EN 7.2

Niet alleen NFS doet dit trouwens, ik heb het wel eens vaker gehad, ook met andere dingen.

Oplossing? Soms heel lang wachten, anders rebooten.

Dergelijke problemen heb ik eigenlijk bij al die machines wel eens, de ene keer erger dan de andere keer. Dit is niet alleen bij df het geval maar ook bij andere dingen.

Heeft iemand enig idee hoe ik hier vanaf kom? Ik kan wordt er namelijk strond ziek van .

Ik ken dit probleem pas sinds ik deze machines ken, op eigen servers, workstations en ander grut heb ik nooit ergens last van gehad.

Vraag 2 . Als 't wel aan NFS ligt, stel die NAS (network attached storage) is overleden, is er dan niets anders aan te doen dan wat ik deed? (laptop in 't netwerk, ip van 't nas en een unconfigured NFS server alles met 'nee' beantwoorden, vervolgens schoot te load omlaag ). Bijvoorbeeld umounten zonder dat 't volume bereikbaar is

Enorm bedankt

[odysseus]

Hmm, je zou als je dat nog niet gedaan het de suggesties uit je thread [ur=http://gathering.tweakers.net/forum/list_messages/353363/1?limit=100]hier[/url] nog eens kunnen proberen, maar ik heb het idee dat je weer met hetzelfde probleem zit. Welke andere processen gaan er nog naar status D behalve NFS en alles wat van NFS gebruik maakt?

* odysseus notes dat jep altijd van die moeilijke problemen heeft ...

[jep]

Op zaterdag 04 mei 2002 12:18 schreef odysseus het volgende:
Hmm, je zou als je dat nog niet gedaan het de suggesties uit je thread [ur=http://gathering.tweakers.net/forum/list_messages/353363/1?limit=100]hier[/url] nog eens kunnen proberen, maar ik heb het idee dat je weer met hetzelfde probleem zit. Welke andere processen gaan er nog naar status D behalve NFS en alles wat van NFS gebruik maakt?

Nouuu...... ik weet niet meer wat het was , SSH deed 't iig ook, maar dat lag aan een ietwat brakke kernel en da's dus opgelost. Maar toch

Wat bijvoorbeeld lullig was, ik heb een script genaamd diskcheck dat elke paar minuten de vrije ruimte in de gaten houd en me optrommelt indien nodig maar toen er een NAS stierf ging nfs bokken en elke zoveel minuten ging de load verder omhoog omdat df werd opgeroepen.. conclusie. load 60 waardoor sendmail weer alles gaat lopen rejecten en dat schiet allemaal niet op . Ik doe nu maar df -l

* odysseus notes dat jep altijd van die moeilijke problemen heeft ...

Ik vraag 't pas als ik 't zelf niet op kan lossen. Meestal kom ik er trouwens wel met groups.google.com maarnee

[jep]

Zal ik anders maar SMB mouten naar dat NAS

[Valium]

of ftp mounten, of gewoon ftp, of scp....ligt eraan wat je wilt.

Wel een vaag probleem hoor. Nog nooit eerder gehoord.

[jep]

Ik heb 't geloof ik ook alleen met NFS mounts naar die NAS systemen (verder nfs ik niet echt heel veel).

FTP draaien die dingen niet, dus we gaan maar voor smb dan .

code:

[root@audrey2 root]# uptime
  5:14pm  up 2 days,  9:11,  2 users,  load average: 3.05, 3.01, 3.00
[root@audrey2 root]# ps auxc | grep df
root       5  0.0  0.0     0    0 ?   SW   May02   0:00 bdflush
root     28922  0.0  0.1  1664  640 ?     D    02:34   0:00 df
root    7362  0.0  0.1  1664  640 ?   D    11:08   0:00 df

Ziet u?

Bij top zijn die processen trouwens helemaal niet druk ofzo, het is iets van 't rondvliegen van dwaze dingen in io space, zo vertelde mensen mij .

Ik heb 't idee dat die bak keurig rustig is, maar ik ga 'm op een rustig moment toch weer rebooten want dit is zeker niet netjes.

[deadinspace]

Op zaterdag 04 mei 2002 11:23 schreef jep het volgende:
Voorbeeld: NFS. Ik weet nu niet meer of NFS zo stinkt of dat er iets anders vreselijk brak is maar ik mount dus elke nacht een NFS volume. Bijna altijd gaat dit goed maar nu tik ik vanmorgen bijvoorbeeld df -h en komt hij niet tot dat volume.. en toen was de load 1 . Als ik vervolgens niet oplet gaan er meer dingen naar D omdat die weer van df gebruik maken .

Ikzelf ben niet zo onder de indruk van NFS (vooral vanwege starheid en slechte mogelijkheden tot beveiliging).
Maar gebruik je wel soft-NFS mounting? Dat was iirc makkelijker als een share onbereikbaar was.

Op zaterdag 04 mei 2002 17:16 schreef jep het volgende:
Bij top zijn die processen trouwens helemaal niet druk ofzo, het is iets van 't rondvliegen van dwaze dingen in io space, zo vertelde mensen mij .

Processes die status D zijn wachten op I/O van de kernel (in dit geval van NFS). Totdat ze die I/O krijgen doen die processes helemaal niks meer (ook geen signals verwerken).

Ik heb 't idee dat die bak keurig rustig is

Afaik kosten die processes geen CPU, maar ze worden wel door de scheduler gescheduled als kostende 100% CPU. Daardoor wordt de load dus 1+, maar op het moment dat deze processes aan de beurt komen zijn ze meteen klaar omdat ze pas weer iets gaan doen als ze van status D af komen.
Maar dat is dus afaik.

[jep]

Op zaterdag 04 mei 2002 20:28 schreef deadinspace het volgende:

[..]

Ikzelf ben niet zo onder de indruk van NFS (vooral vanwege starheid en slechte mogelijkheden tot beveiliging).
Maar gebruik je wel soft-NFS mounting? Dat was iirc makkelijker als een share onbereikbaar was.
[..]

Ja, ik gebruik softmounting, dat had ik ook bedacht maar haalde dus niets uit.

Processes die status D zijn wachten op I/O van de kernel (in dit geval van NFS). Totdat ze die I/O krijgen doen die processes helemaal niks meer (ook geen signals verwerken).
[..]

I noticed.

Afaik kosten die processes geen CPU, maar ze worden wel door de scheduler gescheduled als kostende 100% CPU. Daardoor wordt de load dus 1+, maar op het moment dat deze processes aan de beurt komen zijn ze meteen klaar omdat ze pas weer iets gaan doen als ze van status D af komen.
Maar dat is dus afaik.

Yeah. Ik bedoelde dat een reboot of een ingreep naar mijn mening geen hele grote haast heeft omdat de machine gewoon heel snel blijft. Dat getal van die load (die nu overigens 3.00 3.00 3.00 is) staat me alleen niet aan .

[odysseus]

Ik mag aannemen dat je te mounten partitie op een andere pc staat? In dat geval kun je daar misschien een connectie vinden naar je eigen pc en daar wat signalen doorheen gooien om duidelijk te maken dat het mounten niet doorgaat. Het proces in status D wacht in feite op data die niet komt, het zou er in theorie uit kunnen komen door die data toch te sturen...

[jep]

Op zaterdag 04 mei 2002 20:50 schreef odysseus het volgende:
Ik mag aannemen dat je te mounten partitie op een andere pc staat? In dat geval kun je daar misschien een connectie vinden naar je eigen pc en daar wat signalen doorheen gooien om duidelijk te maken dat het mounten niet doorgaat. Het proces in status D wacht in feite op data die niet komt, het zou er in theorie uit kunnen komen door die data toch te sturen...

Nee helaas. Ik mount een powervault (240 gig raid5) NAS systeempje van dell waarop ik niet kan pielen enzo. Ook de logs vertellen mij niets speciaals. Het gekke is dan de andere servers 'm wel kunnen mounten..

Deze wellicht ook wel weer hoor, maar 't ging met deze mount (?) dus weer mis. Althans.. dat denk ik omdat df weer niet voorbij dat volume komt.

[jep]

Mijn meedenkende baas dacht iets slims

Als het aan het nasje ligt, zouden we het een tijdje op een "PC" met nfs kunnen proberen, echter, ik denk ook dat het NFS is die gewoon nogal star is...


Hmmmmm kunnen het probleem ook bij Dell neerleggen, die leveren namenlijk de NAS appliance, de Servers EN geven aan RedHat daarbij te gebruiken.

Why not