ce soir je remarque un truc bizarre : alors que je vaque à mes occupations
habituelles du soir (mail, news, administration/tuning/màj système...) après
un apt-get install ma charge système (indiquée par wmmon) s'est envolée pour
stagner autour de 6.
Je regarde dans top et je ne vois rien de bizarre, mieux le système (Debian
2.4.26 smp) est idle à plus de 98%. Bien qu'il indique par ailleurs que la
charge est autour de 6 avec une moyenne de 5.
Le temps que je cherche un peu et que je rédige ce message, je vois que la
charge est redescendue mais c'est resté comme cela environ 20 minutes. Aucun
trafic particulier sur le disque dur ni le réseau. J'ai même regardé avec le
chercheprocess de François Boisson.
Pour la prochaine fois, où faut-il chercher les process qui «chargent» le
système ?
Pour la prochaine fois, où faut-il chercher les process qui «chargent» le système ?
Tiens, je viens de voir un truc dans le /var/log/messages :
Oct 26 22:54:46 obelix kernel: inserting floppy driver for 2.4.26-1-686-smp Oct 26 22:54:46 obelix kernel: FDC 0 is a post-1991 82077 Oct 26 22:55:09 obelix kernel: end_request: I/O error, dev 02:00 (floppy), sector 0 Oct 26 22:55:31 obelix kernel: end_request: I/O error, dev 02:00 (floppy), sector 0 Oct 26 22:55:54 obelix kernel: end_request: I/O error, dev 02:00 (floppy), sector 1 [...] Oct 26 23:15:25 obelix kernel: end_request: I/O error, dev 16:40 (hdd), sector 0 Oct 26 23:15:25 obelix kernel: end_request: I/O error, dev 16:40 (hdd), sector 2 Oct 26 23:15:25 obelix kernel: end_request: I/O error, dev 16:40 (hdd), sector 4 [...]
Ça correspond à peu près à la période avec une charge élevée. Ce qui est rigolo c'est que je n'ai pas de floppy dans cette machine (bios configuré en conséquence) et que hdd est le graveur de dvd (avec un dvd monté mais pas en utilisation à ce moment)...
Sébastien Kirche
Le 26 oct 2004, Sebastien Kirche vraute :
Pour la prochaine fois, où faut-il chercher les process qui «chargent» le
système ?
Tiens, je viens de voir un truc dans le /var/log/messages :
Oct 26 22:54:46 obelix kernel: inserting floppy driver for 2.4.26-1-686-smp
Oct 26 22:54:46 obelix kernel: FDC 0 is a post-1991 82077
Oct 26 22:55:09 obelix kernel: end_request: I/O error, dev 02:00 (floppy), sector 0
Oct 26 22:55:31 obelix kernel: end_request: I/O error, dev 02:00 (floppy), sector 0
Oct 26 22:55:54 obelix kernel: end_request: I/O error, dev 02:00 (floppy), sector 1
[...]
Oct 26 23:15:25 obelix kernel: end_request: I/O error, dev 16:40 (hdd), sector 0
Oct 26 23:15:25 obelix kernel: end_request: I/O error, dev 16:40 (hdd), sector 2
Oct 26 23:15:25 obelix kernel: end_request: I/O error, dev 16:40 (hdd), sector 4
[...]
Ça correspond à peu près à la période avec une charge élevée.
Ce qui est rigolo c'est que je n'ai pas de floppy dans cette machine (bios
configuré en conséquence) et que hdd est le graveur de dvd (avec un dvd
monté mais pas en utilisation à ce moment)...
Pour la prochaine fois, où faut-il chercher les process qui «chargent» le système ?
Tiens, je viens de voir un truc dans le /var/log/messages :
Oct 26 22:54:46 obelix kernel: inserting floppy driver for 2.4.26-1-686-smp Oct 26 22:54:46 obelix kernel: FDC 0 is a post-1991 82077 Oct 26 22:55:09 obelix kernel: end_request: I/O error, dev 02:00 (floppy), sector 0 Oct 26 22:55:31 obelix kernel: end_request: I/O error, dev 02:00 (floppy), sector 0 Oct 26 22:55:54 obelix kernel: end_request: I/O error, dev 02:00 (floppy), sector 1 [...] Oct 26 23:15:25 obelix kernel: end_request: I/O error, dev 16:40 (hdd), sector 0 Oct 26 23:15:25 obelix kernel: end_request: I/O error, dev 16:40 (hdd), sector 2 Oct 26 23:15:25 obelix kernel: end_request: I/O error, dev 16:40 (hdd), sector 4 [...]
Ça correspond à peu près à la période avec une charge élevée. Ce qui est rigolo c'est que je n'ai pas de floppy dans cette machine (bios configuré en conséquence) et que hdd est le graveur de dvd (avec un dvd monté mais pas en utilisation à ce moment)...
Sébastien Kirche
Th. Boudet
Sebastien Kirche wrote:
Pour la prochaine fois, où faut-il chercher les process qui «chargent» le système ?
Tiens, je viens de voir un truc dans le /var/log/messages :
Oct 26 22:55:54 obelix kernel: end_request: I/O error, dev 02:00 (floppy), sector 1 [...] Oct 26 23:15:25 obelix kernel: end_request: I/O error, dev 16:40 (hdd), sector 0
Ça correspond à peu près à la période avec une charge élevée.
Peut-être la maj de la base slocate ou un nettoyage des core qui est lancé par le cron à ce moment-là et essaye de parcourir tous les fs montés ?
Sebastien Kirche wrote:
Pour la prochaine fois, où faut-il chercher les process qui «chargent» le
système ?
Tiens, je viens de voir un truc dans le /var/log/messages :
Oct 26 22:55:54 obelix kernel: end_request: I/O error, dev 02:00 (floppy), sector 1
[...]
Oct 26 23:15:25 obelix kernel: end_request: I/O error, dev 16:40 (hdd), sector 0
Ça correspond à peu près à la période avec une charge élevée.
Peut-être la maj de la base slocate ou un nettoyage des core
qui est lancé par le cron à ce moment-là et essaye de parcourir
tous les fs montés ?
Pour la prochaine fois, où faut-il chercher les process qui «chargent» le système ?
Tiens, je viens de voir un truc dans le /var/log/messages :
Oct 26 22:55:54 obelix kernel: end_request: I/O error, dev 02:00 (floppy), sector 1 [...] Oct 26 23:15:25 obelix kernel: end_request: I/O error, dev 16:40 (hdd), sector 0
Ça correspond à peu près à la période avec une charge élevée.
Peut-être la maj de la base slocate ou un nettoyage des core qui est lancé par le cron à ce moment-là et essaye de parcourir tous les fs montés ?
Rakotomandimby Mihamina
On Wed, 27 Oct 2004 10:21:10 +0200, Th. Boudet wrote:
Tiens, je viens de voir un truc dans le /var/log/messages :
Oct 26 22:55:54 obelix kernel: end_request: I/O error, dev 02:00 (floppy), sector 1 [...] Oct 26 23:15:25 obelix kernel: end_request: I/O error, dev 16:40 (hdd), sector 0
Ça correspond à peu près à la période avec une charge élevée.
Peut-être la maj de la base slocate ou un nettoyage des core qui est lancé par le cron à ce moment-là et essaye de parcourir tous les fs montés ?
Statistiquement (chez moi): 99% des erreurs I/O sont dues à une corrruption du FS (ou de la table des partition je sais plus). un fsck à detecté le problème et l'a corrigé.
Je pense que tu devrqis commencer par là. En effet continuer à écrire sur une partition dont la table ne correspond pas à ce qu'il en est exactement, c'est un risque. Et comme on ne sait pas par où commencer, autant commencer par là ...
N'oublie pas de nous tenir au courant Sebastien.
-- ASPO Infogérance - http://aspo.rktmb.org/activites/infogerance Unofficial FAQ fcolc - http://faq.fcolc.eu.org/ Linux User Group sur Orléans et alentours. Tél: + 33 2 38 76 43 65 (France)
On Wed, 27 Oct 2004 10:21:10 +0200, Th. Boudet wrote:
Tiens, je viens de voir un truc dans le /var/log/messages :
Oct 26 22:55:54 obelix kernel: end_request: I/O error, dev 02:00
(floppy), sector 1 [...]
Oct 26 23:15:25 obelix kernel: end_request: I/O error, dev 16:40 (hdd),
sector 0
Ça correspond à peu près à la période avec une charge élevée.
Peut-être la maj de la base slocate ou un nettoyage des core qui
est lancé par le cron à ce moment-là et essaye de parcourir tous
les fs montés ?
Statistiquement (chez moi): 99% des erreurs I/O sont dues à une
corrruption du FS (ou de la table des partition je sais plus). un fsck à
detecté le problème et l'a corrigé.
Je pense que tu devrqis commencer par là. En effet continuer à écrire
sur une partition dont la table ne correspond pas à ce qu'il en est
exactement, c'est un risque. Et comme on ne sait pas par où commencer,
autant commencer par là ...
N'oublie pas de nous tenir au courant Sebastien.
--
ASPO Infogérance - http://aspo.rktmb.org/activites/infogerance
Unofficial FAQ fcolc - http://faq.fcolc.eu.org/
Linux User Group sur Orléans et alentours.
Tél: + 33 2 38 76 43 65 (France)
On Wed, 27 Oct 2004 10:21:10 +0200, Th. Boudet wrote:
Tiens, je viens de voir un truc dans le /var/log/messages :
Oct 26 22:55:54 obelix kernel: end_request: I/O error, dev 02:00 (floppy), sector 1 [...] Oct 26 23:15:25 obelix kernel: end_request: I/O error, dev 16:40 (hdd), sector 0
Ça correspond à peu près à la période avec une charge élevée.
Peut-être la maj de la base slocate ou un nettoyage des core qui est lancé par le cron à ce moment-là et essaye de parcourir tous les fs montés ?
Statistiquement (chez moi): 99% des erreurs I/O sont dues à une corrruption du FS (ou de la table des partition je sais plus). un fsck à detecté le problème et l'a corrigé.
Je pense que tu devrqis commencer par là. En effet continuer à écrire sur une partition dont la table ne correspond pas à ce qu'il en est exactement, c'est un risque. Et comme on ne sait pas par où commencer, autant commencer par là ...
N'oublie pas de nous tenir au courant Sebastien.
-- ASPO Infogérance - http://aspo.rktmb.org/activites/infogerance Unofficial FAQ fcolc - http://faq.fcolc.eu.org/ Linux User Group sur Orléans et alentours. Tél: + 33 2 38 76 43 65 (France)
Bruno Mathieu
Sebastien Kirche a écrit:
Ça correspond à peu près à la période avec une charge élevée. Ce qui est rigolo c'est que je n'ai pas de floppy dans cette machine (bios configuré en conséquence) et que hdd est le graveur de dvd (avec un dvd monté mais pas en utilisation à ce moment)...
Recherche /dev/fd0, /dev/floppy, /dev/hdd ... dans tous les fichiers de /etc. Des distributions installent des fichiers de configuration pas forcément syncro avec le matériel ;-) C'est l'occasion de peaufiner.
Rakotomandimby Mihamina a raison : un FS un peu corrompu produit des choses bizarres (un reboot brutal de la machine quand je faisait vi /etc/fstab sur une reiserfs corrompue à cause de sales manip pour utiliser software suspend/pmdisk).
Rq : Si c'est / qui est corrompu, et en reiserfs, il faut forcément booter sur un autre support (un cd d'install par exemple) : le remonter en écriture seule ne suffit pas a faire accepter reiserfsck. Ou je n'y suis pas parvenu.
-- Bruno
Sebastien Kirche a écrit:
Ça correspond à peu près à la période avec une charge élevée.
Ce qui est rigolo c'est que je n'ai pas de floppy dans cette machine
(bios configuré en conséquence) et que hdd est le graveur de dvd (avec
un dvd monté mais pas en utilisation à ce moment)...
Recherche /dev/fd0, /dev/floppy, /dev/hdd ... dans tous les fichiers
de /etc. Des distributions installent des fichiers de configuration pas
forcément syncro avec le matériel ;-) C'est l'occasion de peaufiner.
Rakotomandimby Mihamina a raison : un FS un peu corrompu produit des choses
bizarres (un reboot brutal de la machine quand je faisait vi /etc/fstab sur
une reiserfs corrompue à cause de sales manip pour utiliser software
suspend/pmdisk).
Rq : Si c'est / qui est corrompu, et en reiserfs, il faut forcément booter
sur un autre support (un cd d'install par exemple) : le remonter en
écriture seule ne suffit pas a faire accepter reiserfsck. Ou je n'y suis
pas parvenu.
Ça correspond à peu près à la période avec une charge élevée. Ce qui est rigolo c'est que je n'ai pas de floppy dans cette machine (bios configuré en conséquence) et que hdd est le graveur de dvd (avec un dvd monté mais pas en utilisation à ce moment)...
Recherche /dev/fd0, /dev/floppy, /dev/hdd ... dans tous les fichiers de /etc. Des distributions installent des fichiers de configuration pas forcément syncro avec le matériel ;-) C'est l'occasion de peaufiner.
Rakotomandimby Mihamina a raison : un FS un peu corrompu produit des choses bizarres (un reboot brutal de la machine quand je faisait vi /etc/fstab sur une reiserfs corrompue à cause de sales manip pour utiliser software suspend/pmdisk).
Rq : Si c'est / qui est corrompu, et en reiserfs, il faut forcément booter sur un autre support (un cd d'install par exemple) : le remonter en écriture seule ne suffit pas a faire accepter reiserfsck. Ou je n'y suis pas parvenu.
-- Bruno
Sebastien Kirche
Le 27 Oct 2004, Bruno Mathieu vraute :
Recherche /dev/fd0, /dev/floppy, /dev/hdd ... dans tous les fichiers de /etc. Des distributions installent des fichiers de configuration pas forcément syncro avec le matériel ;-) C'est l'occasion de peaufiner.
Il faut que je vérifie, effectivement. Je penche aussi pour cette solution.
Sébastien Kirche
Le 27 Oct 2004, Bruno Mathieu vraute :
Recherche /dev/fd0, /dev/floppy, /dev/hdd ... dans tous les fichiers
de /etc. Des distributions installent des fichiers de configuration pas
forcément syncro avec le matériel ;-) C'est l'occasion de peaufiner.
Il faut que je vérifie, effectivement. Je penche aussi pour cette solution.
Recherche /dev/fd0, /dev/floppy, /dev/hdd ... dans tous les fichiers de /etc. Des distributions installent des fichiers de configuration pas forcément syncro avec le matériel ;-) C'est l'occasion de peaufiner.
Il faut que je vérifie, effectivement. Je penche aussi pour cette solution.
Sébastien Kirche
Sebastien Kirche
Le 27 Oct 2004, Rakotomandimby Mihamina s'est exprimé ainsi :
On Wed, 27 Oct 2004 10:21:10 +0200, Th. Boudet wrote:
Tiens, je viens de voir un truc dans le /var/log/messages :
Oct 26 22:55:54 obelix kernel: end_request: I/O error, dev 02:00 (floppy), sector 1 [...] Oct 26 23:15:25 obelix kernel: end_request: I/O error, dev 16:40 (hdd), sector 0
Ça correspond à peu près à la période avec une charge élevée.
Peut-être la maj de la base slocate ou un nettoyage des core qui est lancé par le cron à ce moment-là et essaye de parcourir tous les fs montés ?
Je suppose. Quoique pour hdd je comprends mais pour floppy, hum.
Je viens de vérifier la crontab : ça ne colle pas. La machine tourne tout le temps en ce moment et les tâches sont lancées entre 6:00 et 7:00. Et pour la hourly à hh:17.
Statistiquement (chez moi): 99% des erreurs I/O sont dues à une corrruption du FS (ou de la table des partition je sais plus). un fsck à detecté le problème et l'a corrigé.
Sinon un truc m'échappe : si ma culture générale unix ne me fait pas défaut, le nombre qui représente la charge c'est le nombre de processus dans la file en attente de traitement par le processeur/scheduler (en gros). Je ne vois pas comment elle pourrait monter et se maintenir à 6 alors qu'en même temps je suis quasiment entièrement idle...
Je pense que tu devrqis commencer par là. En effet continuer à écrire sur une partition dont la table ne correspond pas à ce qu'il en est exactement, c'est un risque. Et comme on ne sait pas par où commencer, autant commencer par là ...
Je veux bien, mais comment je fais un fsck sur un lecteur qui n'existe pas (floppy) ou sur un medium en lecture seule (hdd) ? :P
Ou tu veux dire comme Bruno Mathieu de vérifier / qui pourrait faire yoyoter le système ?
N'oublie pas de nous tenir au courant Sebastien.
Voui voui. Ce soir je vais investiguer un peu plus et je vous dirais.
Sébastien Kirche
Le 27 Oct 2004, Rakotomandimby Mihamina s'est exprimé ainsi :
On Wed, 27 Oct 2004 10:21:10 +0200, Th. Boudet wrote:
Tiens, je viens de voir un truc dans le /var/log/messages :
Oct 26 22:55:54 obelix kernel: end_request: I/O error, dev 02:00
(floppy), sector 1 [...] Oct 26 23:15:25 obelix kernel: end_request:
I/O error, dev 16:40 (hdd), sector 0
Ça correspond à peu près à la période avec une charge élevée.
Peut-être la maj de la base slocate ou un nettoyage des core qui
est lancé par le cron à ce moment-là et essaye de parcourir tous
les fs montés ?
Je suppose. Quoique pour hdd je comprends mais pour floppy, hum.
Je viens de vérifier la crontab : ça ne colle pas. La machine tourne tout le
temps en ce moment et les tâches sont lancées entre 6:00 et 7:00. Et pour la
hourly à hh:17.
Statistiquement (chez moi): 99% des erreurs I/O sont dues à une
corrruption du FS (ou de la table des partition je sais plus). un fsck à
detecté le problème et l'a corrigé.
Sinon un truc m'échappe : si ma culture générale unix ne me fait pas défaut,
le nombre qui représente la charge c'est le nombre de processus dans la file
en attente de traitement par le processeur/scheduler (en gros).
Je ne vois pas comment elle pourrait monter et se maintenir à 6 alors qu'en
même temps je suis quasiment entièrement idle...
Je pense que tu devrqis commencer par là. En effet continuer à écrire
sur une partition dont la table ne correspond pas à ce qu'il en est
exactement, c'est un risque. Et comme on ne sait pas par où commencer,
autant commencer par là ...
Je veux bien, mais comment je fais un fsck sur un lecteur qui n'existe pas
(floppy) ou sur un medium en lecture seule (hdd) ? :P
Ou tu veux dire comme Bruno Mathieu de vérifier / qui pourrait faire yoyoter
le système ?
N'oublie pas de nous tenir au courant Sebastien.
Voui voui. Ce soir je vais investiguer un peu plus et je vous dirais.
Le 27 Oct 2004, Rakotomandimby Mihamina s'est exprimé ainsi :
On Wed, 27 Oct 2004 10:21:10 +0200, Th. Boudet wrote:
Tiens, je viens de voir un truc dans le /var/log/messages :
Oct 26 22:55:54 obelix kernel: end_request: I/O error, dev 02:00 (floppy), sector 1 [...] Oct 26 23:15:25 obelix kernel: end_request: I/O error, dev 16:40 (hdd), sector 0
Ça correspond à peu près à la période avec une charge élevée.
Peut-être la maj de la base slocate ou un nettoyage des core qui est lancé par le cron à ce moment-là et essaye de parcourir tous les fs montés ?
Je suppose. Quoique pour hdd je comprends mais pour floppy, hum.
Je viens de vérifier la crontab : ça ne colle pas. La machine tourne tout le temps en ce moment et les tâches sont lancées entre 6:00 et 7:00. Et pour la hourly à hh:17.
Statistiquement (chez moi): 99% des erreurs I/O sont dues à une corrruption du FS (ou de la table des partition je sais plus). un fsck à detecté le problème et l'a corrigé.
Sinon un truc m'échappe : si ma culture générale unix ne me fait pas défaut, le nombre qui représente la charge c'est le nombre de processus dans la file en attente de traitement par le processeur/scheduler (en gros). Je ne vois pas comment elle pourrait monter et se maintenir à 6 alors qu'en même temps je suis quasiment entièrement idle...
Je pense que tu devrqis commencer par là. En effet continuer à écrire sur une partition dont la table ne correspond pas à ce qu'il en est exactement, c'est un risque. Et comme on ne sait pas par où commencer, autant commencer par là ...
Je veux bien, mais comment je fais un fsck sur un lecteur qui n'existe pas (floppy) ou sur un medium en lecture seule (hdd) ? :P
Ou tu veux dire comme Bruno Mathieu de vérifier / qui pourrait faire yoyoter le système ?
N'oublie pas de nous tenir au courant Sebastien.
Voui voui. Ce soir je vais investiguer un peu plus et je vous dirais.
Sébastien Kirche
TiChou
Dans le message <news:, *Sebastien Kirche* tapota sur f.c.o.l.configuration :
Sinon un truc m'échappe : si ma culture générale unix ne me fait pas défaut, le nombre qui représente la charge c'est le nombre de processus dans la file en attente de traitement par le processeur/scheduler (en gros). Je ne vois pas comment elle pourrait monter et se maintenir à 6 alors qu'en même temps je suis quasiment entièrement idle...
Oui, mais n'oublie pas que la charge est une moyenne faite sur le temps et qu'elle n'est pas représentative de la charge à un instant t. Généralement la charge est calculée sur 1 minute, 5 minutes et 15 minutes. Laquelle de ces valeurs as-tu lu ?
-- TiChou
Dans le message <news:m2wtxcnzgh.fsf@seki.fr>,
*Sebastien Kirche* tapota sur f.c.o.l.configuration :
Sinon un truc m'échappe : si ma culture générale unix ne me fait pas
défaut, le nombre qui représente la charge c'est le nombre de processus
dans la file en attente de traitement par le processeur/scheduler (en
gros). Je ne vois pas comment elle pourrait monter et se maintenir à 6
alors qu'en même temps je suis quasiment entièrement idle...
Oui, mais n'oublie pas que la charge est une moyenne faite sur le temps et
qu'elle n'est pas représentative de la charge à un instant t. Généralement
la charge est calculée sur 1 minute, 5 minutes et 15 minutes. Laquelle de
ces valeurs as-tu lu ?
Dans le message <news:, *Sebastien Kirche* tapota sur f.c.o.l.configuration :
Sinon un truc m'échappe : si ma culture générale unix ne me fait pas défaut, le nombre qui représente la charge c'est le nombre de processus dans la file en attente de traitement par le processeur/scheduler (en gros). Je ne vois pas comment elle pourrait monter et se maintenir à 6 alors qu'en même temps je suis quasiment entièrement idle...
Oui, mais n'oublie pas que la charge est une moyenne faite sur le temps et qu'elle n'est pas représentative de la charge à un instant t. Généralement la charge est calculée sur 1 minute, 5 minutes et 15 minutes. Laquelle de ces valeurs as-tu lu ?
-- TiChou
Nicolas George
Sebastien Kirche wrote in message :
Sinon un truc m'échappe : si ma culture générale unix ne me fait pas défaut, le nombre qui représente la charge c'est le nombre de processus dans la file en attente de traitement par le processeur/scheduler (en gros). Je ne vois pas comment elle pourrait monter et se maintenir à 6 alors qu'en même temps je suis quasiment entièrement idle...
L'explication est très simple : la charge compte aussi les processus en attente d'entrée/sortie. Quand il y a quelque chose de pourri avec des drivers de périphériques (erreurs sur un disque, USB bloqué, etc.), certains processus passent dans l'infâme état D (attente ininterruptible). Dans ce cas, il ne chargent pas le processeur, mais comptent pour le load average.
Sebastien Kirche wrote in message <m2wtxcnzgh.fsf@seki.fr>:
Sinon un truc m'échappe : si ma culture générale unix ne me fait pas défaut,
le nombre qui représente la charge c'est le nombre de processus dans la file
en attente de traitement par le processeur/scheduler (en gros).
Je ne vois pas comment elle pourrait monter et se maintenir à 6 alors qu'en
même temps je suis quasiment entièrement idle...
L'explication est très simple : la charge compte aussi les processus en
attente d'entrée/sortie. Quand il y a quelque chose de pourri avec des
drivers de périphériques (erreurs sur un disque, USB bloqué, etc.), certains
processus passent dans l'infâme état D (attente ininterruptible). Dans ce
cas, il ne chargent pas le processeur, mais comptent pour le load average.
Sinon un truc m'échappe : si ma culture générale unix ne me fait pas défaut, le nombre qui représente la charge c'est le nombre de processus dans la file en attente de traitement par le processeur/scheduler (en gros). Je ne vois pas comment elle pourrait monter et se maintenir à 6 alors qu'en même temps je suis quasiment entièrement idle...
L'explication est très simple : la charge compte aussi les processus en attente d'entrée/sortie. Quand il y a quelque chose de pourri avec des drivers de périphériques (erreurs sur un disque, USB bloqué, etc.), certains processus passent dans l'infâme état D (attente ininterruptible). Dans ce cas, il ne chargent pas le processeur, mais comptent pour le load average.
Sebastien Kirche
Le 27 Oct 2004, TiChou s'est exprimé ainsi :
Dans le message <news:, *Sebastien Kirche* tapota sur f.c.o.l.configuration :
Sinon un truc m'échappe : si ma culture générale unix ne me fait pas défaut, le nombre qui représente la charge c'est le nombre de processus dans la file en attente de traitement par le processeur/scheduler (en gros). Je ne vois pas comment elle pourrait monter et se maintenir à 6 alors qu'en même temps je suis quasiment entièrement idle...
Oui, mais n'oublie pas que la charge est une moyenne faite sur le temps et qu'elle n'est pas représentative de la charge à un instant t. Généralement la charge est calculée sur 1 minute, 5 minutes et 15 minutes. Laquelle de ces valeurs as-tu lu ?
La charge indiquée par wmmon était stable vers 6 sans pic ni creux visible.
Pour top, j'avais 6.xx / 5.xx / je sais plus le 3ème nombre. En même temps que idle 98.x %
Je voulais copier exactement la sortie de top pour garder une trace mais je ne l'ai pas fait tout de suite et quand je l'ai tenté elle était sortie du tampon du terminal.
Sébastien Kirche
Le 27 Oct 2004, TiChou s'est exprimé ainsi :
Dans le message <news:m2wtxcnzgh.fsf@seki.fr>,
*Sebastien Kirche* tapota sur f.c.o.l.configuration :
Sinon un truc m'échappe : si ma culture générale unix ne me fait pas
défaut, le nombre qui représente la charge c'est le nombre de processus
dans la file en attente de traitement par le processeur/scheduler (en
gros). Je ne vois pas comment elle pourrait monter et se maintenir à 6
alors qu'en même temps je suis quasiment entièrement idle...
Oui, mais n'oublie pas que la charge est une moyenne faite sur le
temps et qu'elle n'est pas représentative de la charge à un instant t.
Généralement la charge est calculée sur 1 minute, 5 minutes et 15
minutes. Laquelle de ces valeurs as-tu lu ?
La charge indiquée par wmmon était stable vers 6 sans pic ni creux visible.
Pour top, j'avais 6.xx / 5.xx / je sais plus le 3ème nombre. En même temps
que idle 98.x %
Je voulais copier exactement la sortie de top pour garder une trace mais je
ne l'ai pas fait tout de suite et quand je l'ai tenté elle était sortie du
tampon du terminal.
Dans le message <news:, *Sebastien Kirche* tapota sur f.c.o.l.configuration :
Sinon un truc m'échappe : si ma culture générale unix ne me fait pas défaut, le nombre qui représente la charge c'est le nombre de processus dans la file en attente de traitement par le processeur/scheduler (en gros). Je ne vois pas comment elle pourrait monter et se maintenir à 6 alors qu'en même temps je suis quasiment entièrement idle...
Oui, mais n'oublie pas que la charge est une moyenne faite sur le temps et qu'elle n'est pas représentative de la charge à un instant t. Généralement la charge est calculée sur 1 minute, 5 minutes et 15 minutes. Laquelle de ces valeurs as-tu lu ?
La charge indiquée par wmmon était stable vers 6 sans pic ni creux visible.
Pour top, j'avais 6.xx / 5.xx / je sais plus le 3ème nombre. En même temps que idle 98.x %
Je voulais copier exactement la sortie de top pour garder une trace mais je ne l'ai pas fait tout de suite et quand je l'ai tenté elle était sortie du tampon du terminal.
Sébastien Kirche
Sebastien Kirche
Le 27 Oct 2004, Nicolas George s'est exprimé ainsi :
L'explication est très simple : la charge compte aussi les processus en attente d'entrée/sortie. Quand il y a quelque chose de pourri avec des drivers de périphériques (erreurs sur un disque, USB bloqué, etc.), certains processus passent dans l'infâme état D (attente ininterruptible). Dans ce cas, il ne chargent pas le processeur, mais comptent pour le load average.
J'ai pensé un truc comme ça une fois que j'ai vu les logs d'erreur de lecture sur des périphériques fantômes.
Merci de la mise au point.
Tiens en passant : à propos de ce foutu état D que je traduis par "attente sur le matériel", il n'y a *aucun* moyen de tuer un process dans cet état ?
Ça m'a déjà fait rebooter, et c'est le fsck assuré quand c'est un process en attente sur un fichier/une partition (vu avec l'ancien noyau buggé de ma Sparc) :(
Sébastien Kirche
Le 27 Oct 2004, Nicolas George s'est exprimé ainsi :
L'explication est très simple : la charge compte aussi les processus en
attente d'entrée/sortie. Quand il y a quelque chose de pourri avec des
drivers de périphériques (erreurs sur un disque, USB bloqué, etc.),
certains processus passent dans l'infâme état D (attente ininterruptible).
Dans ce cas, il ne chargent pas le processeur, mais comptent pour le load
average.
J'ai pensé un truc comme ça une fois que j'ai vu les logs d'erreur de
lecture sur des périphériques fantômes.
Merci de la mise au point.
Tiens en passant : à propos de ce foutu état D que je traduis par "attente
sur le matériel", il n'y a *aucun* moyen de tuer un process dans cet état ?
Ça m'a déjà fait rebooter, et c'est le fsck assuré quand c'est un process en
attente sur un fichier/une partition (vu avec l'ancien noyau buggé de ma
Sparc) :(
Le 27 Oct 2004, Nicolas George s'est exprimé ainsi :
L'explication est très simple : la charge compte aussi les processus en attente d'entrée/sortie. Quand il y a quelque chose de pourri avec des drivers de périphériques (erreurs sur un disque, USB bloqué, etc.), certains processus passent dans l'infâme état D (attente ininterruptible). Dans ce cas, il ne chargent pas le processeur, mais comptent pour le load average.
J'ai pensé un truc comme ça une fois que j'ai vu les logs d'erreur de lecture sur des périphériques fantômes.
Merci de la mise au point.
Tiens en passant : à propos de ce foutu état D que je traduis par "attente sur le matériel", il n'y a *aucun* moyen de tuer un process dans cet état ?
Ça m'a déjà fait rebooter, et c'est le fsck assuré quand c'est un process en attente sur un fichier/une partition (vu avec l'ancien noyau buggé de ma Sparc) :(
