Salut,
Je viens de remettre une Squeeze toute neuve sur mon PC portable, acheté
en 2003 (pas très jeune, donc) qui m'a servi pendant ma thèse à faire du
calcul numérique.
Mais c'est la misère, il en chie à la moindre opération (même un clic
droit). J'aimerais bien savoir ce qui déconne, car, a priori quand
j'étais en thèse, il supportait ça relativement bien, et pour ce que je
demande il devrait s'en sortir. Je soupçonne le disque, mais je ne suis
pas sûr.
Y a-t-il un moyen de savoir quel est l'élément incriminé, afin de
pouvoir le changer ?
Merci.
A plus tard.
Salut,
Je viens de remettre une Squeeze toute neuve sur mon PC portable, acheté
en 2003 (pas très jeune, donc) qui m'a servi pendant ma thèse à faire du
calcul numérique.
Mais c'est la misère, il en chie à la moindre opération (même un clic
droit). J'aimerais bien savoir ce qui déconne, car, a priori quand
j'étais en thèse, il supportait ça relativement bien, et pour ce que je
demande il devrait s'en sortir. Je soupçonne le disque, mais je ne suis
pas sûr.
Y a-t-il un moyen de savoir quel est l'élément incriminé, afin de
pouvoir le changer ?
Merci.
A plus tard.
Salut,
Je viens de remettre une Squeeze toute neuve sur mon PC portable, acheté
en 2003 (pas très jeune, donc) qui m'a servi pendant ma thèse à faire du
calcul numérique.
Mais c'est la misère, il en chie à la moindre opération (même un clic
droit). J'aimerais bien savoir ce qui déconne, car, a priori quand
j'étais en thèse, il supportait ça relativement bien, et pour ce que je
demande il devrait s'en sortir. Je soupçonne le disque, mais je ne suis
pas sûr.
Y a-t-il un moyen de savoir quel est l'élément incriminé, afin de
pouvoir le changer ?
Merci.
A plus tard.
Je viens de remettre une Squeeze toute neuve sur mon PC portable, acheté
en 2003 (pas très jeune, donc) qui m'a servi pendant ma thèse à faire du
calcul numérique.
Mais c'est la misère, il en chie à la moindre opération (même un clic
droit). J'aimerais bien savoir ce qui déconne, car, a priori quand
j'étais en thèse, il supportait ça relativement bien, et pour ce que je
demande il devrait s'en sortir. Je soupçonne le disque, mais je ne suis
pas sûr.
Y a-t-il un moyen de savoir quel est l'élément incriminé, afin de
pouvoir le changer ?
Je viens de remettre une Squeeze toute neuve sur mon PC portable, acheté
en 2003 (pas très jeune, donc) qui m'a servi pendant ma thèse à faire du
calcul numérique.
Mais c'est la misère, il en chie à la moindre opération (même un clic
droit). J'aimerais bien savoir ce qui déconne, car, a priori quand
j'étais en thèse, il supportait ça relativement bien, et pour ce que je
demande il devrait s'en sortir. Je soupçonne le disque, mais je ne suis
pas sûr.
Y a-t-il un moyen de savoir quel est l'élément incriminé, afin de
pouvoir le changer ?
Je viens de remettre une Squeeze toute neuve sur mon PC portable, acheté
en 2003 (pas très jeune, donc) qui m'a servi pendant ma thèse à faire du
calcul numérique.
Mais c'est la misère, il en chie à la moindre opération (même un clic
droit). J'aimerais bien savoir ce qui déconne, car, a priori quand
j'étais en thèse, il supportait ça relativement bien, et pour ce que je
demande il devrait s'en sortir. Je soupçonne le disque, mais je ne suis
pas sûr.
Y a-t-il un moyen de savoir quel est l'élément incriminé, afin de
pouvoir le changer ?
Quand ça rame c'est la ram...
Blague à part, depuis ta thèse les choses ont du changer. Tu ne dis pas un
mot sur l'interface graphique, c'est peut-être ça qui fait rame r? Alors est-
ce la même qu'avant? et c'est quoi au fait? et quelle version?
D'autre part es-tu sûr d'avoir assez de Ram et assez de swap?
Sur les serveurs, je commence toujours par un petit "w" qui me donne
l'uptime, la charge et les utilisateurs, puis un free -h pour la Ram.
Après, pour rester dans des trucs simples:
dmesg | tail
tail /var/log/syslog
J'aime bien aussi voir ce qui se passe dans /tmp, genre il est très plein
avec "df -h" (quand /tmp est dans sa propre partition) ou "sudo du -sh
/tmp/*"
... et bien sûr tout ce qu'a dit tv.debian
Avec ça on arrive à savoir si c'est un manque de Ram, de swap, un /tmp en
désordre, un processus qui part en vrille, etc. Et si tout est norma l on
s'interroge sur le matériel.
Il y aussi une solution expresse:
commencer avec un live-cd, adapté à la bécanne, pour voir si ça tourne bien.
Par exemple une Knoppix de 2003 (kde 3.x, noyau 2.4, tourne très bie n avec
128 Mo de Ram) ou la dernière Knoppix (elle est très allég ée) ou encore
SystemRescueCD, qu'on devrait toujours avoir sous la main.
Les live-cd plantent assez vite si le matériel déconne, et quan d ils
tournent bien, on sait tout de suite que le problème vient du syst ème
installé.
bon courage
Quand ça rame c'est la ram...
Blague à part, depuis ta thèse les choses ont du changer. Tu ne dis pas un
mot sur l'interface graphique, c'est peut-être ça qui fait rame r? Alors est-
ce la même qu'avant? et c'est quoi au fait? et quelle version?
D'autre part es-tu sûr d'avoir assez de Ram et assez de swap?
Sur les serveurs, je commence toujours par un petit "w" qui me donne
l'uptime, la charge et les utilisateurs, puis un free -h pour la Ram.
Après, pour rester dans des trucs simples:
dmesg | tail
tail /var/log/syslog
J'aime bien aussi voir ce qui se passe dans /tmp, genre il est très plein
avec "df -h" (quand /tmp est dans sa propre partition) ou "sudo du -sh
/tmp/*"
... et bien sûr tout ce qu'a dit tv.debian
Avec ça on arrive à savoir si c'est un manque de Ram, de swap, un /tmp en
désordre, un processus qui part en vrille, etc. Et si tout est norma l on
s'interroge sur le matériel.
Il y aussi une solution expresse:
commencer avec un live-cd, adapté à la bécanne, pour voir si ça tourne bien.
Par exemple une Knoppix de 2003 (kde 3.x, noyau 2.4, tourne très bie n avec
128 Mo de Ram) ou la dernière Knoppix (elle est très allég ée) ou encore
SystemRescueCD, qu'on devrait toujours avoir sous la main.
Les live-cd plantent assez vite si le matériel déconne, et quan d ils
tournent bien, on sait tout de suite que le problème vient du syst ème
installé.
bon courage
Quand ça rame c'est la ram...
Blague à part, depuis ta thèse les choses ont du changer. Tu ne dis pas un
mot sur l'interface graphique, c'est peut-être ça qui fait rame r? Alors est-
ce la même qu'avant? et c'est quoi au fait? et quelle version?
D'autre part es-tu sûr d'avoir assez de Ram et assez de swap?
Sur les serveurs, je commence toujours par un petit "w" qui me donne
l'uptime, la charge et les utilisateurs, puis un free -h pour la Ram.
Après, pour rester dans des trucs simples:
dmesg | tail
tail /var/log/syslog
J'aime bien aussi voir ce qui se passe dans /tmp, genre il est très plein
avec "df -h" (quand /tmp est dans sa propre partition) ou "sudo du -sh
/tmp/*"
... et bien sûr tout ce qu'a dit tv.debian
Avec ça on arrive à savoir si c'est un manque de Ram, de swap, un /tmp en
désordre, un processus qui part en vrille, etc. Et si tout est norma l on
s'interroge sur le matériel.
Il y aussi une solution expresse:
commencer avec un live-cd, adapté à la bécanne, pour voir si ça tourne bien.
Par exemple une Knoppix de 2003 (kde 3.x, noyau 2.4, tourne très bie n avec
128 Mo de Ram) ou la dernière Knoppix (elle est très allég ée) ou encore
SystemRescueCD, qu'on devrait toujours avoir sous la main.
Les live-cd plantent assez vite si le matériel déconne, et quan d ils
tournent bien, on sait tout de suite que le problème vient du syst ème
installé.
bon courage
Merci de ce rappel utile.
Avec la commande "top", j'ai cette première ligne :
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
517 root 20 0 151m 23m 696 R 92.1 3.0 12:49.14 kerneloops
%CPU = 92,41%
Pisteur d'erreurs noyau (« oops ») :
"kerneloops" est un démon qui collecte des informations sur les plantages
du noyau puis envoie la signature extraite au site web kerneloops.org
pour une analyse statistique et une présentation aux développeurs du noyau Linux.
Est-ce normal que le processus "kerneloops" occupe 92,41% du CPU ?
Merci.
Merci de ce rappel utile.
Avec la commande "top", j'ai cette première ligne :
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
517 root 20 0 151m 23m 696 R 92.1 3.0 12:49.14 kerneloops
%CPU = 92,41%
Pisteur d'erreurs noyau (« oops ») :
"kerneloops" est un démon qui collecte des informations sur les plantages
du noyau puis envoie la signature extraite au site web kerneloops.org
pour une analyse statistique et une présentation aux développeurs du noyau Linux.
Est-ce normal que le processus "kerneloops" occupe 92,41% du CPU ?
Merci.
Merci de ce rappel utile.
Avec la commande "top", j'ai cette première ligne :
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
517 root 20 0 151m 23m 696 R 92.1 3.0 12:49.14 kerneloops
%CPU = 92,41%
Pisteur d'erreurs noyau (« oops ») :
"kerneloops" est un démon qui collecte des informations sur les plantages
du noyau puis envoie la signature extraite au site web kerneloops.org
pour une analyse statistique et une présentation aux développeurs du noyau Linux.
Est-ce normal que le processus "kerneloops" occupe 92,41% du CPU ?
Merci.
wrote:
Le 14/12/2010 10:47, a écrit :Avec la commande "top", j'ai cette première ligne :
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+
COMMAND
517 root 20 0 151m 23m 696 R 92.1 3.0 12:49.14
kerneloops
%CPU = 92,41%
Est-ce normal que le processus "kerneloops" occupe 92,41% du CPU
Pas normal du tout, dans un premier temps tu peux tuer "kerneloops",
ensuite il faut trouver pourquoi il se lance à chaque démarrage
tv.debian@googlemail.com wrote:
Le 14/12/2010 10:47, corbie@free.fr a écrit :
Avec la commande "top", j'ai cette première ligne :
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+
COMMAND
517 root 20 0 151m 23m 696 R 92.1 3.0 12:49.14
kerneloops
%CPU = 92,41%
Est-ce normal que le processus "kerneloops" occupe 92,41% du CPU
Pas normal du tout, dans un premier temps tu peux tuer "kerneloops",
ensuite il faut trouver pourquoi il se lance à chaque démarrage
wrote:
Le 14/12/2010 10:47, a écrit :Avec la commande "top", j'ai cette première ligne :
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+
COMMAND
517 root 20 0 151m 23m 696 R 92.1 3.0 12:49.14
kerneloops
%CPU = 92,41%
Est-ce normal que le processus "kerneloops" occupe 92,41% du CPU
Pas normal du tout, dans un premier temps tu peux tuer "kerneloops",
ensuite il faut trouver pourquoi il se lance à chaque démarrage
Quand ça rame c'est la ram...
Blague à part, depuis ta thèse les choses ont du changer.
Tu ne dis pas un
mot sur l'interface graphique, c'est peut-être ça qui fait ramer? Alors est-
ce la même qu'avant? et c'est quoi au fait? et quelle version?
D'autre part es-tu sûr d'avoir assez de Ram et assez de swap?
Sur les serveurs, je commence toujours par un petit "w" qui me donne
l'uptime, la charge et les utilisateurs, puis un free -h pour la Ram.
Après, pour rester dans des trucs simples:
dmesg | tail
tail /var/log/syslog
J'aime bien aussi voir ce qui se passe dans /tmp, genre il est très plein
avec "df -h" (quand /tmp est dans sa propre partition) ou "sudo du -sh
/tmp/*"
commence simple, regarde un "top" ou "htop"[1] pour voir si tu as un
processus qui te pompe ton processeur. Vérifie quel pilote graphique tu
utilises ( "grep -i driver /var/log/Xorg.0.log" )
et les éventuels
problèmes qui y sont liés ( "egrep '((WW)|(EE))' /var/log/Xorg.0.log" ).
Si tout baigne regarde l'utilisation du disque avec "iotop"[2] par
exemple, son état de santé avec "smart"[3] (juste un indicateur, pas
infaillible).
Regarde /var/log/syslog pour détecter un problème récurrent.
Quand ça rame c'est la ram...
Blague à part, depuis ta thèse les choses ont du changer.
Tu ne dis pas un
mot sur l'interface graphique, c'est peut-être ça qui fait ramer? Alors est-
ce la même qu'avant? et c'est quoi au fait? et quelle version?
D'autre part es-tu sûr d'avoir assez de Ram et assez de swap?
Sur les serveurs, je commence toujours par un petit "w" qui me donne
l'uptime, la charge et les utilisateurs, puis un free -h pour la Ram.
Après, pour rester dans des trucs simples:
dmesg | tail
tail /var/log/syslog
J'aime bien aussi voir ce qui se passe dans /tmp, genre il est très plein
avec "df -h" (quand /tmp est dans sa propre partition) ou "sudo du -sh
/tmp/*"
commence simple, regarde un "top" ou "htop"[1] pour voir si tu as un
processus qui te pompe ton processeur. Vérifie quel pilote graphique tu
utilises ( "grep -i driver /var/log/Xorg.0.log" )
et les éventuels
problèmes qui y sont liés ( "egrep '((WW)|(EE))' /var/log/Xorg.0.log" ).
Si tout baigne regarde l'utilisation du disque avec "iotop"[2] par
exemple, son état de santé avec "smart"[3] (juste un indicateur, pas
infaillible).
Regarde /var/log/syslog pour détecter un problème récurrent.
Quand ça rame c'est la ram...
Blague à part, depuis ta thèse les choses ont du changer.
Tu ne dis pas un
mot sur l'interface graphique, c'est peut-être ça qui fait ramer? Alors est-
ce la même qu'avant? et c'est quoi au fait? et quelle version?
D'autre part es-tu sûr d'avoir assez de Ram et assez de swap?
Sur les serveurs, je commence toujours par un petit "w" qui me donne
l'uptime, la charge et les utilisateurs, puis un free -h pour la Ram.
Après, pour rester dans des trucs simples:
dmesg | tail
tail /var/log/syslog
J'aime bien aussi voir ce qui se passe dans /tmp, genre il est très plein
avec "df -h" (quand /tmp est dans sa propre partition) ou "sudo du -sh
/tmp/*"
commence simple, regarde un "top" ou "htop"[1] pour voir si tu as un
processus qui te pompe ton processeur. Vérifie quel pilote graphique tu
utilises ( "grep -i driver /var/log/Xorg.0.log" )
et les éventuels
problèmes qui y sont liés ( "egrep '((WW)|(EE))' /var/log/Xorg.0.log" ).
Si tout baigne regarde l'utilisation du disque avec "iotop"[2] par
exemple, son état de santé avec "smart"[3] (juste un indicateur, pas
infaillible).
Regarde /var/log/syslog pour détecter un problème récurrent.
> Avec la commande "top", j'ai cette première ligne :
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMM AND
> 517 root 20 0 151m 23m 696 R 92.1 3.0 12:49.14 k erneloops
> %CPU = 92,41%
> Pas normal du tout, dans un premier temps tu peux tuer "kerneloops",
A mon avis, il y a un rapport en cours, qui merde. Ça m'est arrivà © aussi.
C'est quoi ton noyau (uname -a) ? :
Arrête kerneloops avec "/etc/init.d/kerneloops stop" puis relance le pour voir.
> ensuite il faut trouver pourquoi il se lance à chaque démarra ge
C'est normal. Il est lancé par défaut depuis un bout de temps d éjà .
Tu peux t'en passer, c'est surtout de l'aide pour les développeurs n oyaux.
Désactive le dans /etc/rc2.d :
Pas normal du tout, dans un premier temps tu peux tuer "kerneloops",
ensuite il faut trouver pourquoi il se lance à chaque démarrage (si
c'est bien le cas). Cherche le crash noyau qui lance le oops dans
"dmesg", /var/log/messages (et /var/log/kern.log) :
Enfin le comportement de kerneloops ressemble à un bon gros bug, que lle
taille fait /var/log/messages ? :
> Avec la commande "top", j'ai cette première ligne :
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMM AND
> 517 root 20 0 151m 23m 696 R 92.1 3.0 12:49.14 k erneloops
> %CPU = 92,41%
> Pas normal du tout, dans un premier temps tu peux tuer "kerneloops",
A mon avis, il y a un rapport en cours, qui merde. Ãa m'est arrivà © aussi.
C'est quoi ton noyau (uname -a) ? :
Arrête kerneloops avec "/etc/init.d/kerneloops stop" puis relance le pour voir.
> ensuite il faut trouver pourquoi il se lance à chaque démarra ge
C'est normal. Il est lancé par défaut depuis un bout de temps d éjà .
Tu peux t'en passer, c'est surtout de l'aide pour les développeurs n oyaux.
Désactive le dans /etc/rc2.d :
Pas normal du tout, dans un premier temps tu peux tuer "kerneloops",
ensuite il faut trouver pourquoi il se lance à chaque démarrage (si
c'est bien le cas). Cherche le crash noyau qui lance le oops dans
"dmesg", /var/log/messages (et /var/log/kern.log) :
Enfin le comportement de kerneloops ressemble à un bon gros bug, que lle
taille fait /var/log/messages ? :
> Avec la commande "top", j'ai cette première ligne :
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMM AND
> 517 root 20 0 151m 23m 696 R 92.1 3.0 12:49.14 k erneloops
> %CPU = 92,41%
> Pas normal du tout, dans un premier temps tu peux tuer "kerneloops",
A mon avis, il y a un rapport en cours, qui merde. Ça m'est arrivà © aussi.
C'est quoi ton noyau (uname -a) ? :
Arrête kerneloops avec "/etc/init.d/kerneloops stop" puis relance le pour voir.
> ensuite il faut trouver pourquoi il se lance à chaque démarra ge
C'est normal. Il est lancé par défaut depuis un bout de temps d éjà .
Tu peux t'en passer, c'est surtout de l'aide pour les développeurs n oyaux.
Désactive le dans /etc/rc2.d :
Pas normal du tout, dans un premier temps tu peux tuer "kerneloops",
ensuite il faut trouver pourquoi il se lance à chaque démarrage (si
c'est bien le cas). Cherche le crash noyau qui lance le oops dans
"dmesg", /var/log/messages (et /var/log/kern.log) :
Enfin le comportement de kerneloops ressemble à un bon gros bug, que lle
taille fait /var/log/messages ? :
quelle taille fait /var/log/messages ? :
22.528.080 octets
quelle taille fait /var/log/messages ? :
22.528.080 octets
quelle taille fait /var/log/messages ? :
22.528.080 octets
On Tue, Dec 14, 2010 at 10:26:28AM +0100, Xavier Brochard wrote :
free -h me dit que -h n'est pas une option recevable.
Mais bon, je vais vérifier cette histoire de 256Mo, il me semble que
c'était plus.
On Tue, Dec 14, 2010 at 10:26:28AM +0100, Xavier Brochard wrote :
free -h me dit que -h n'est pas une option recevable.
Mais bon, je vais vérifier cette histoire de 256Mo, il me semble que
c'était plus.
On Tue, Dec 14, 2010 at 10:26:28AM +0100, Xavier Brochard wrote :
free -h me dit que -h n'est pas une option recevable.
Mais bon, je vais vérifier cette histoire de 256Mo, il me semble que
c'était plus.
wrote:
>> quelle taille fait /var/log/messages ? :
> 22.528.080 octets
22 Mo, rien que ça!
si tu veux l'effacer il faudra passer en mode mono utilisateur
soit au démarrage, soit comme ça:
ferme ta session graphique, logge-toi root en console, et tape "telinit 1 "
(le chiffre un)
ensuite tu efface /var/log/messages et tu redémarre
rm /var/log/messages => reboot. xavier
corbie@free.fr wrote:
>> quelle taille fait /var/log/messages ? :
> 22.528.080 octets
22 Mo, rien que ça!
si tu veux l'effacer il faudra passer en mode mono utilisateur
soit au démarrage, soit comme ça:
ferme ta session graphique, logge-toi root en console, et tape "telinit 1 "
(le chiffre un)
ensuite tu efface /var/log/messages et tu redémarre
rm /var/log/messages => reboot. xavier
wrote:
>> quelle taille fait /var/log/messages ? :
> 22.528.080 octets
22 Mo, rien que ça!
si tu veux l'effacer il faudra passer en mode mono utilisateur
soit au démarrage, soit comme ça:
ferme ta session graphique, logge-toi root en console, et tape "telinit 1 "
(le chiffre un)
ensuite tu efface /var/log/messages et tu redémarre
rm /var/log/messages => reboot. xavier