Après une migration, je trouve mon nouveau serveur debian plus lent que le
précédent, fort encombrement de la mémoire, et forte utilisation du CPU
alors que le serveur n'est quasiment pas sollicité. Comment savoir à quoi
correspondent toutes ces commandes fuser lancées sur le serveur ?
En tout cas, la solution testée règle le problème des lenteurs.
Tout désinstaller aussi.
YBM
Le 16/03/2014 11:15, Julien Arlandis a écrit :
Le Dim. 16 mars 2014 à 10:49, Nicolas George a écrit :
Julien Arlandis , dans le message , a écrit :
Une solution trouvée ici : http://memo-linux.com/zombie-ubuntu-11-10-fuser-100-cpu/
« Solution »... Une astuce trouvée au hasard, sans comprendre l'origine du problème et les conséquences du changement proposé. Typique de ce que font les utilisateurs d'ubuntu et de php.
Certes, je sais que l'origine du problème est située dans cette tâche cron :
ça nettoie les vieilles sessions PHP5, le fuser permet d'éviter d'effacer les fichiers de sessions des connexions HTTP en cours.
Le problème met en lumière un bug de fuser (psmisc) qui a été corrigé upstream, des paquets Ubuntu sont dispo, Debian je ne sais pas, mais c'est pas difficile de recompiler psmisc en applicant le patch :
Le Dim. 16 mars 2014 à 10:49, Nicolas George a écrit :
Julien Arlandis , dans le message
<8ebf761c05d2a6d530037974a5e04eb5a23b4d34@devnews.nemoweb.net>, a
écrit :
Une solution trouvée ici :
http://memo-linux.com/zombie-ubuntu-11-10-fuser-100-cpu/
« Solution »... Une astuce trouvée au hasard, sans comprendre l'origine du
problème et les conséquences du changement proposé. Typique de ce que font
les utilisateurs d'ubuntu et de php.
Certes, je sais que l'origine du problème est située dans cette tâche
cron :
ça nettoie les vieilles sessions PHP5, le fuser permet d'éviter
d'effacer les fichiers de sessions des connexions HTTP en cours.
Le problème met en lumière un bug de fuser (psmisc) qui a été
corrigé upstream, des paquets Ubuntu sont dispo, Debian je ne
sais pas, mais c'est pas difficile de recompiler psmisc en
applicant le patch :
Le Dim. 16 mars 2014 à 10:49, Nicolas George a écrit :
Julien Arlandis , dans le message , a écrit :
Une solution trouvée ici : http://memo-linux.com/zombie-ubuntu-11-10-fuser-100-cpu/
« Solution »... Une astuce trouvée au hasard, sans comprendre l'origine du problème et les conséquences du changement proposé. Typique de ce que font les utilisateurs d'ubuntu et de php.
Certes, je sais que l'origine du problème est située dans cette tâche cron :
ça nettoie les vieilles sessions PHP5, le fuser permet d'éviter d'effacer les fichiers de sessions des connexions HTTP en cours.
Le problème met en lumière un bug de fuser (psmisc) qui a été corrigé upstream, des paquets Ubuntu sont dispo, Debian je ne sais pas, mais c'est pas difficile de recompiler psmisc en applicant le patch :
Le Dim. 16 mars 2014 à 10:49, Nicolas George a écrit :
Julien Arlandis , dans le message , a écrit :
Une solution trouvée ici : http://memo-linux.com/zombie-ubuntu-11-10-fuser-100-cpu/
« Solution »... Une astuce trouvée au hasard, sans comprendre l'origine du problème et les conséquences du changement proposé. Typique de ce que font les utilisateurs d'ubuntu et de php.
Certes, je sais que l'origine du problème est située dans cette tâche cron :
ça nettoie les vieilles sessions PHP5, le fuser permet d'éviter d'effacer les fichiers de sessions des connexions HTTP en cours.
Le problème met en lumière un bug de fuser (psmisc) qui a été corrigé upstream, des paquets Ubuntu sont dispo, Debian je ne sais pas, mais c'est pas difficile de recompiler psmisc en applicant le patch :
Merci pour l'explication. Je ne comprends pas cette syntaxe [ -x /usr/lib/php5/maxlifetime ], ce n'est pas une commande bash c'est quoi?
-- Ce message a été posté avec Nemo : <http://news.julien-arlandis.fr/?Jid
Le Lun. 17 mars 2014 à 12:11, YBM a écrit :
Le 16/03/2014 11:15, Julien Arlandis a écrit :
Le Dim. 16 mars 2014 à 10:49, Nicolas George a écrit :
Julien Arlandis , dans le message
<8ebf761c05d2a6d530037974a5e04eb5a23b4d34@devnews.nemoweb.net>, a
écrit :
Une solution trouvée ici :
http://memo-linux.com/zombie-ubuntu-11-10-fuser-100-cpu/
« Solution »... Une astuce trouvée au hasard, sans comprendre l'origine du
problème et les conséquences du changement proposé. Typique de ce que font
les utilisateurs d'ubuntu et de php.
Certes, je sais que l'origine du problème est située dans cette tâche
cron :
ça nettoie les vieilles sessions PHP5, le fuser permet d'éviter
d'effacer les fichiers de sessions des connexions HTTP en cours.
Le problème met en lumière un bug de fuser (psmisc) qui a été
corrigé upstream, des paquets Ubuntu sont dispo, Debian je ne
sais pas, mais c'est pas difficile de recompiler psmisc en
applicant le patch :
Le Dim. 16 mars 2014 à 10:49, Nicolas George a écrit :
Julien Arlandis , dans le message , a écrit :
Une solution trouvée ici : http://memo-linux.com/zombie-ubuntu-11-10-fuser-100-cpu/
« Solution »... Une astuce trouvée au hasard, sans comprendre l'origine du problème et les conséquences du changement proposé. Typique de ce que font les utilisateurs d'ubuntu et de php.
Certes, je sais que l'origine du problème est située dans cette tâche cron :
ça nettoie les vieilles sessions PHP5, le fuser permet d'éviter d'effacer les fichiers de sessions des connexions HTTP en cours.
Le problème met en lumière un bug de fuser (psmisc) qui a été corrigé upstream, des paquets Ubuntu sont dispo, Debian je ne sais pas, mais c'est pas difficile de recompiler psmisc en applicant le patch :
Merci pour l'explication. Je ne comprends pas cette syntaxe [ -x /usr/lib/php5/maxlifetime ], ce n'est pas une commande bash c'est quoi?
si c'est une commande bash interne, (cf. help [ ) ça renvoie vrai (0) si le fichier est exécutable par l'utilisateur courant : $ [ -x /usr/lib/php5/maxlifetime ] ; echo $? 0 $ /usr/lib/php5/maxlifetime 24
Merci pour l'explication.
Je ne comprends pas cette syntaxe
[ -x /usr/lib/php5/maxlifetime ], ce n'est pas une commande bash c'est
quoi?
si c'est une commande bash interne, (cf. help [ )
ça renvoie vrai (0) si le fichier est exécutable par l'utilisateur
courant :
$ [ -x /usr/lib/php5/maxlifetime ] ; echo $?
0
$ /usr/lib/php5/maxlifetime
24
Merci pour l'explication. Je ne comprends pas cette syntaxe [ -x /usr/lib/php5/maxlifetime ], ce n'est pas une commande bash c'est quoi?
si c'est une commande bash interne, (cf. help [ ) ça renvoie vrai (0) si le fichier est exécutable par l'utilisateur courant : $ [ -x /usr/lib/php5/maxlifetime ] ; echo $? 0 $ /usr/lib/php5/maxlifetime 24
Erwan David
Julien Arlandis écrivait :
Le Lun. 17 mars 2014 à 12:11, YBM a écrit :
Le 16/03/2014 11:15, Julien Arlandis a écrit :
Le Dim. 16 mars 2014 à 10:49, Nicolas George a écrit :
Julien Arlandis , dans le message , a écrit :
Une solution trouvée ici : http://memo-linux.com/zombie-ubuntu-11-10-fuser-100-cpu/
« Solution »... Une astuce trouvée au hasard, sans comprendre l'origine du problème et les conséquences du changement proposé. Typique de ce que font les utilisateurs d'ubuntu et de php.
Certes, je sais que l'origine du problème est située dans cette tâche cron :
ça nettoie les vieilles sessions PHP5, le fuser permet d'éviter d'effacer les fichiers de sessions des connexions HTTP en cours.
Le problème met en lumière un bug de fuser (psmisc) qui a été corrigé upstream, des paquets Ubuntu sont dispo, Debian je ne sais pas, mais c'est pas difficile de recompiler psmisc en applicant le patch :
Le Dim. 16 mars 2014 à 10:49, Nicolas George a écrit :
Julien Arlandis , dans le message
<8ebf761c05d2a6d530037974a5e04eb5a23b4d34@devnews.nemoweb.net>, a
écrit :
Une solution trouvée ici :
http://memo-linux.com/zombie-ubuntu-11-10-fuser-100-cpu/
« Solution »... Une astuce trouvée au hasard, sans comprendre l'origine du
problème et les conséquences du changement proposé. Typique de ce que font
les utilisateurs d'ubuntu et de php.
Certes, je sais que l'origine du problème est située dans cette tâche
cron :
ça nettoie les vieilles sessions PHP5, le fuser permet d'éviter
d'effacer les fichiers de sessions des connexions HTTP en cours.
Le problème met en lumière un bug de fuser (psmisc) qui a été
corrigé upstream, des paquets Ubuntu sont dispo, Debian je ne
sais pas, mais c'est pas difficile de recompiler psmisc en
applicant le patch :
Le Dim. 16 mars 2014 à 10:49, Nicolas George a écrit :
Julien Arlandis , dans le message , a écrit :
Une solution trouvée ici : http://memo-linux.com/zombie-ubuntu-11-10-fuser-100-cpu/
« Solution »... Une astuce trouvée au hasard, sans comprendre l'origine du problème et les conséquences du changement proposé. Typique de ce que font les utilisateurs d'ubuntu et de php.
Certes, je sais que l'origine du problème est située dans cette tâche cron :
ça nettoie les vieilles sessions PHP5, le fuser permet d'éviter d'effacer les fichiers de sessions des connexions HTTP en cours.
Le problème met en lumière un bug de fuser (psmisc) qui a été corrigé upstream, des paquets Ubuntu sont dispo, Debian je ne sais pas, mais c'est pas difficile de recompiler psmisc en applicant le patch :
Merci pour l'explication. Je ne comprends pas cette syntaxe [ -x /usr/lib/php5/maxlifetime ], ce n'est pas une commande bash c'est quoi?
man test
-- Les simplifications c'est trop compliqué
Erwan David
Eric Jacoboni écrivait :
Le 17/03/2014 22:47, Th.A.C a écrit :
Le 17/03/2014 21:18, Eric Jacoboni a écrit :
% help test zsh: command not found: help
sous bash: % help test test: test [expr]
Nan, mais je sais...
C'était juste pour indiquer que la commande help n'était pas disponible systématiquement et qu'il ne fallait pas sombrer dans le bashomorphisme...
D'autant que les crontab sont exécutées par sh, pas par bash. Et que si sur certaines distributions, sh est un lien vers bash, ce n'est pas le cas par défaut sur debian, où le sh utilisé est dash.
-- Les simplifications c'est trop compliqué
Eric Jacoboni <eric.jacoboni@gmail.com> écrivait :
Le 17/03/2014 22:47, Th.A.C a écrit :
Le 17/03/2014 21:18, Eric Jacoboni a écrit :
% help test
zsh: command not found: help
sous bash:
% help test
test: test [expr]
Nan, mais je sais...
C'était juste pour indiquer que la commande help n'était pas disponible
systématiquement et qu'il ne fallait pas sombrer dans le bashomorphisme...
D'autant que les crontab sont exécutées par sh, pas par bash. Et que si
sur certaines distributions, sh est un lien vers bash, ce n'est pas le
cas par défaut sur debian, où le sh utilisé est dash.
C'était juste pour indiquer que la commande help n'était pas disponible systématiquement et qu'il ne fallait pas sombrer dans le bashomorphisme...
D'autant que les crontab sont exécutées par sh, pas par bash. Et que si sur certaines distributions, sh est un lien vers bash, ce n'est pas le cas par défaut sur debian, où le sh utilisé est dash.
-- Les simplifications c'est trop compliqué
Benoit Izac
Bonjour,
le 18/03/2014 à 07:58, Erwan David a écrit dans le message :
% help test zsh: command not found: help
sous bash: % help test test: test [expr]
Nan, mais je sais...
C'était juste pour indiquer que la commande help n'était pas disponible systématiquement et qu'il ne fallait pas sombrer dans le bashomorphisme...
D'autant que les crontab sont exécutées par sh, pas par bash. Et que si sur certaines distributions, sh est un lien vers bash, ce n'est pas le cas par défaut sur debian, où le sh utilisé est dash.
Le mieux reste encore de consulter la spécification qui doit être respectée par tous les Bourne shell du marché (/bin/test également) : <http://pubs.opengroup.org/onlinepubs/009695399/utilities/test.html>.
-- Benoit Izac
Bonjour,
le 18/03/2014 à 07:58, Erwan David a écrit dans le message
<87fvmgat7m.fsf@tee.rail.eu.org> :
% help test
zsh: command not found: help
sous bash:
% help test
test: test [expr]
Nan, mais je sais...
C'était juste pour indiquer que la commande help n'était pas disponible
systématiquement et qu'il ne fallait pas sombrer dans le bashomorphisme...
D'autant que les crontab sont exécutées par sh, pas par bash. Et que si
sur certaines distributions, sh est un lien vers bash, ce n'est pas le
cas par défaut sur debian, où le sh utilisé est dash.
Le mieux reste encore de consulter la spécification qui doit être
respectée par tous les Bourne shell du marché (/bin/test également) :
<http://pubs.opengroup.org/onlinepubs/009695399/utilities/test.html>.
le 18/03/2014 à 07:58, Erwan David a écrit dans le message :
% help test zsh: command not found: help
sous bash: % help test test: test [expr]
Nan, mais je sais...
C'était juste pour indiquer que la commande help n'était pas disponible systématiquement et qu'il ne fallait pas sombrer dans le bashomorphisme...
D'autant que les crontab sont exécutées par sh, pas par bash. Et que si sur certaines distributions, sh est un lien vers bash, ce n'est pas le cas par défaut sur debian, où le sh utilisé est dash.
Le mieux reste encore de consulter la spécification qui doit être respectée par tous les Bourne shell du marché (/bin/test également) : <http://pubs.opengroup.org/onlinepubs/009695399/utilities/test.html>.
