[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: daemon lancé au démarrage qui "bouffe" toute la cpu !!!



éffectivement avec un export de LC_NUMERIC=POSIX et "sleep 0.1" dans le
bash je n'ai plus de pb.

Merci à tous pour votre aide

Patrick

Le jeudi 12 mai 2005 à 13:32 +0200, François TOURDE a écrit :
> Le 12915ième jour après Epoch,
> Patrick Noël écrivait:
> 
> > oui mais comment expliquer que juste en faisant un restart du daemon je
> > n'ai plus le pb, la conso cpu redevient normale. 
> 
> Ben juste parce que les locales ne sont pas les mêmes... Entre le . et
> la , sleep va réagir de façon différente, générer une erreur
> (invisible pour toi car tu fais 2>/dev/null), et du coup plus de sleep
> et conso à fond.
> 
> > d'autre part avec un ps -aux je ne vois pas les process qui consomment
> > la cpu !
> 
> C'est 'ls' qui consomme tout, mais tu ne le vois pas car ce n'est
> jamais le même. Regarde le 'forkrate' et tu vas être surpris ;)
> 
> >
> > Patrick
> >
> > Le jeudi 12 mai 2005 à 11:13 +0200, François TOURDE a écrit :
> >> Le 12915ième jour après Epoch,
> >> Patrick Noël écrivait:
> >> 
> >> > le sleep 0.1 me donne "sleep: invalid time interval '0.1'"
> >> >
> >> > avec un "sleep 1" cela fonctionne sans problème 
> >> >
> >> > le daemon lancé est un bash qui surveille la présence de fichiers dans
> >> > des dossiers pour les envoyer vers d'autres serveurs. Il contient une
> >> > boucle avec une tempo faite par un "sleep 0,1"
> >> 
> >> Je m'en doutais ;)
> >> 
> >> Extrait:
> >> 
> >> > while [ 1 ]
> >> > do 
> >> [...]
> >> > 	sleep $tempo_util
> >> > 	
> >> > 	dir=`ls -rt --ignore=tmp.* 2> /dev/null | head -n 1`
> >> > 	if [ "$dir" != "" ] 
> >> > 	then
> >> [...]
> >> > 	fi
> >> >
> >> > done 
> >> 
> >> Dans un répertoire initial vide, ton prog boucle indéfiniement et à
> >> toute vitesse. Selon ta machine, et éventuellement un souci sur la
> >> commande sleep, tu vas consommer toute la CPU. Tu précises qu'avec un
> >> sleep 1 ça marche, alors pourquoi ne pas faire ça?
> >> 
> >> D'autre part, un petit prog avec l'utilisation de select(2) devrait
> >> pouvoir améliorer l'attente.
> >> 
> 
> 



Reply to: