J'ai lancé hier soir une sauvegarde avec un
petit fichier, "s" contenant des trucs comme:
tar cjv --exclude=truc -f machin /bidule
etc... etc...
sur un PC distant, donc:
nohup ./s &
exit
hop!
Ce midi la sauvegarde était termininé mais le PC
etait hyper lent! 30 secondes pour s'y loguer, 4
ou 5 secondes avant de repondre a chaque commande
même un simple "ls" ! uptime repondait par des
chose genre "load average: >2, >2, >2" et pourtant,
en tapant "ps aux" le PC ne faisait plus *rien* la
sauvegarde etait terminée depuis plus d'une heure...
Ca depend du rafraichisement. En fait il n'indique rien de plus que ps.
Si, il indique la charge instantannée pour chaque process au moment se l'affichage, ce que ne fait pas ps qui ne montre que les temps consomés cumulés.
ps indique aussi l'instantané dans la colone %CPU. Mais le probleme reste là, comment le PC peut etre aussi chargé sans que ps n'indique rien!
J. Mayer wrote:
Ca depend du rafraichisement. En fait il n'indique rien de plus que ps.
Si, il indique la charge instantannée pour chaque process au moment
se l'affichage, ce que ne fait pas ps qui ne montre que les temps
consomés cumulés.
ps indique aussi l'instantané dans la colone %CPU. Mais le probleme
reste là, comment le PC peut etre aussi chargé sans que ps n'indique
rien!
Ca depend du rafraichisement. En fait il n'indique rien de plus que ps.
Si, il indique la charge instantannée pour chaque process au moment se l'affichage, ce que ne fait pas ps qui ne montre que les temps consomés cumulés.
ps indique aussi l'instantané dans la colone %CPU. Mais le probleme reste là, comment le PC peut etre aussi chargé sans que ps n'indique rien!
Maxime Ritter
Le Sat, 29 Nov 2003 21:31:16 +0100, dans fr.comp.os.linux.configuration, interstellar overdrive a dit :
Y'a pas un updatedb qui s'est lancé au mauvais moment ? Non c'est à 4h du mat ce truc.
Justement, c'est la nuit que la pluspart des distributions choississent pour lancer updatedb.
Tes disques sont bien en UDMA ? Oui, ca change qq chose?
Les accès disques pour des disques IDE non-UDMA (ou non configurés comme tels sous linux, man hdparm) sont très lent et ralentissent énormément le CPU, ça pourrait expliquer....
-- Maxime Ritter | French Computer Geek Mail : | http://maxime.ritter.eu.org
Le Sat, 29 Nov 2003 21:31:16 +0100,
dans fr.comp.os.linux.configuration, interstellar overdrive a dit :
Y'a pas un updatedb qui s'est lancé au mauvais moment ?
Non c'est à 4h du mat ce truc.
Justement, c'est la nuit que la pluspart des distributions choississent
pour lancer updatedb.
Tes disques sont bien en UDMA ?
Oui, ca change qq chose?
Les accès disques pour des disques IDE non-UDMA (ou non configurés comme
tels sous linux, man hdparm) sont très lent et ralentissent énormément le CPU,
ça pourrait expliquer....
--
Maxime Ritter | French Computer Geek
Mail : mritter@alussinan.org | http://maxime.ritter.eu.org
Le Sat, 29 Nov 2003 21:31:16 +0100, dans fr.comp.os.linux.configuration, interstellar overdrive a dit :
Y'a pas un updatedb qui s'est lancé au mauvais moment ? Non c'est à 4h du mat ce truc.
Justement, c'est la nuit que la pluspart des distributions choississent pour lancer updatedb.
Tes disques sont bien en UDMA ? Oui, ca change qq chose?
Les accès disques pour des disques IDE non-UDMA (ou non configurés comme tels sous linux, man hdparm) sont très lent et ralentissent énormément le CPU, ça pourrait expliquer....
-- Maxime Ritter | French Computer Geek Mail : | http://maxime.ritter.eu.org
J. Mayer
On Sun, 30 Nov 2003 20:05:35 +0100, interstellar overdrive wrote:
J. Mayer wrote:
Ca depend du rafraichisement. En fait il n'indique rien de plus que ps.
Si, il indique la charge instantannée pour chaque process au moment se l'affichage, ce que ne fait pas ps qui ne montre que les temps consomés cumulés.
ps indique aussi l'instantané dans la colone %CPU. Mais le probleme reste là, comment le PC peut etre aussi chargé sans que ps n'indique rien!
Dans ce cas, top te dira si le PC passe son temps dans le kernel, si il est bloqué sur des IO... Cpu(s): 11.3% us, 8.5% sy, 0.0% ni, 80.2% id, 0.0% wa, 0.0% hi, 0.0% si Ca donne 11.3% utilisé en mode user (les process), 8.5% par le system 0% en nice 80.2% idle (il ne fait rien). 0% en wait (bloqué sur des IO). ...
On Sun, 30 Nov 2003 20:05:35 +0100, interstellar overdrive wrote:
J. Mayer wrote:
Ca depend du rafraichisement. En fait il n'indique rien de plus que ps.
Si, il indique la charge instantannée pour chaque process au moment
se l'affichage, ce que ne fait pas ps qui ne montre que les temps
consomés cumulés.
ps indique aussi l'instantané dans la colone %CPU. Mais le probleme
reste là, comment le PC peut etre aussi chargé sans que ps n'indique
rien!
Dans ce cas, top te dira si le PC passe son temps dans le kernel,
si il est bloqué sur des IO...
Cpu(s): 11.3% us, 8.5% sy, 0.0% ni, 80.2% id, 0.0% wa, 0.0% hi, 0.0%
si
Ca donne 11.3% utilisé en mode user (les process),
8.5% par le system
0% en nice
80.2% idle (il ne fait rien).
0% en wait (bloqué sur des IO).
...
On Sun, 30 Nov 2003 20:05:35 +0100, interstellar overdrive wrote:
J. Mayer wrote:
Ca depend du rafraichisement. En fait il n'indique rien de plus que ps.
Si, il indique la charge instantannée pour chaque process au moment se l'affichage, ce que ne fait pas ps qui ne montre que les temps consomés cumulés.
ps indique aussi l'instantané dans la colone %CPU. Mais le probleme reste là, comment le PC peut etre aussi chargé sans que ps n'indique rien!
Dans ce cas, top te dira si le PC passe son temps dans le kernel, si il est bloqué sur des IO... Cpu(s): 11.3% us, 8.5% sy, 0.0% ni, 80.2% id, 0.0% wa, 0.0% hi, 0.0% si Ca donne 11.3% utilisé en mode user (les process), 8.5% par le system 0% en nice 80.2% idle (il ne fait rien). 0% en wait (bloqué sur des IO). ...
interstellar overdrive
J. Mayer wrote:
Dans ce cas, top te dira si le PC passe son temps dans le kernel, si il est bloqué sur des IO... Cpu(s): 11.3% us, 8.5% sy, 0.0% ni, 80.2% id, 0.0% wa, 0.0% hi, 0.0% si Ca donne 11.3% utilisé en mode user (les process), 8.5% par le system 0% en nice 80.2% idle (il ne fait rien). 0% en wait (bloqué sur des IO).
ps fait tout cela, exemple ps auxf, et dans mon cas tout etait à quasi < 1% CPU d'ou le mystere ! Bien sur je regrette de n'avoir pas lancer top qui aurait peut etre vu qq chose mais je l'utilise jamais.
J. Mayer wrote:
Dans ce cas, top te dira si le PC passe son temps dans le kernel,
si il est bloqué sur des IO...
Cpu(s): 11.3% us, 8.5% sy, 0.0% ni, 80.2% id, 0.0% wa, 0.0% hi, 0.0%
si
Ca donne 11.3% utilisé en mode user (les process),
8.5% par le system
0% en nice
80.2% idle (il ne fait rien).
0% en wait (bloqué sur des IO).
ps fait tout cela, exemple ps auxf, et dans mon cas tout etait à quasi
< 1% CPU d'ou le mystere ! Bien sur je regrette de n'avoir pas
lancer top qui aurait peut etre vu qq chose mais je l'utilise jamais.
Dans ce cas, top te dira si le PC passe son temps dans le kernel, si il est bloqué sur des IO... Cpu(s): 11.3% us, 8.5% sy, 0.0% ni, 80.2% id, 0.0% wa, 0.0% hi, 0.0% si Ca donne 11.3% utilisé en mode user (les process), 8.5% par le system 0% en nice 80.2% idle (il ne fait rien). 0% en wait (bloqué sur des IO).
ps fait tout cela, exemple ps auxf, et dans mon cas tout etait à quasi < 1% CPU d'ou le mystere ! Bien sur je regrette de n'avoir pas lancer top qui aurait peut etre vu qq chose mais je l'utilise jamais.
interstellar overdrive
Maxime Ritter wrote:
Tes disques sont bien en UDMA ?
Oui, ca change qq chose?
Les accès disques pour des disques IDE non-UDMA (ou non configurés comme tels sous linux, man hdparm) sont très lent et ralentissent énormément le CPU,
Je ne pense pas, mais je sais qu'en comparaison avec freeBSD, Linux gere tres mal les acces aux disques, tout au moins en ext2.
ça pourrait expliquer....
La sauvegarde etait fini depuis pas mal de temps.
Maxime Ritter wrote:
Tes disques sont bien en UDMA ?
Oui, ca change qq chose?
Les accès disques pour des disques IDE non-UDMA (ou non configurés comme
tels sous linux, man hdparm) sont très lent et ralentissent énormément le CPU,
Je ne pense pas, mais je sais qu'en comparaison avec freeBSD, Linux gere
tres mal les acces aux disques, tout au moins en ext2.
Les accès disques pour des disques IDE non-UDMA (ou non configurés comme tels sous linux, man hdparm) sont très lent et ralentissent énormément le CPU,
Je ne pense pas, mais je sais qu'en comparaison avec freeBSD, Linux gere tres mal les acces aux disques, tout au moins en ext2.
D'apres top, il se passe pourtant pas grand chose...
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND 4049 beer 17 0 6048 6044 1772 R 19.2 3.1 5:58 0 smbd 5025 root 12 0 1068 1068 816 R 0.7 0.5 0:00 0 top 4 root 9 0 0 0 0 SW 0.5 0.0 0:26 0 kswapd 11615 donkey 9 0 4712 4712 1036 S 0.1 2.4 15:20 0 overnet0.50.1 5001 beer 9 0 1388 1344 1220 S 0.1 0.7 0:00 0 sshd 1 root 8 0 80 68 52 S 0.0 0.0 0:04 0 init
Mais si on regarde dans syslog:
ec 1 00:21:29 server kernel: end_request: I/O error, dev 03:04 (hda), sector 3464344 Dec 1 00:21:44 server kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error } Dec 1 00:21:44 server kernel: hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect 14728751, sector464344
Arrgg!!!
J. Mayer
On Mon, 01 Dec 2003 00:02:07 +0100, interstellar overdrive wrote:
J. Mayer wrote:
Dans ce cas, top te dira si le PC passe son temps dans le kernel, si il est bloqué sur des IO... Cpu(s): 11.3% us, 8.5% sy, 0.0% ni, 80.2% id, 0.0% wa, 0.0% hi, 0.0% si Ca donne 11.3% utilisé en mode user (les process), 8.5% par le system 0% en nice 80.2% idle (il ne fait rien). 0% en wait (bloqué sur des IO).
ps fait tout cela, exemple ps auxf, et dans mon cas tout etait à quasi < 1% CPU d'ou le mystere ! Bien sur je regrette de n'avoir pas lancer top qui aurait peut etre vu qq chose mais je l'utilise jamais.
Bah non, il ne donne pas la répartition des temps d'utilisation. Je viens de vérifier, et ça tombe bien, POSIX dit la même chose. Il y a peut-être d'autres options qui font celà, mais celles que tu donnes sont censé respecter POSIX. Si c'est le cas, sur ta distrib, dépèche toi d'en installer une autre !
D'après le mail que tu as posté (erreurs disques), si top ne te dis pas que ton CPU passe la majeure partie de son temps à attendre des IO, alors soit ton installation est rootkitée, soit ta distrib est buggée...
D'ailleurs, avec un load-average comme celui-là, load average: 3.53, 2.93, 1.65 il est strictement impossible que le CPU soit occupé à moins de 1% en moyenne...
On Mon, 01 Dec 2003 00:02:07 +0100, interstellar overdrive wrote:
J. Mayer wrote:
Dans ce cas, top te dira si le PC passe son temps dans le kernel,
si il est bloqué sur des IO...
Cpu(s): 11.3% us, 8.5% sy, 0.0% ni, 80.2% id, 0.0% wa, 0.0% hi, 0.0%
si
Ca donne 11.3% utilisé en mode user (les process),
8.5% par le system
0% en nice
80.2% idle (il ne fait rien).
0% en wait (bloqué sur des IO).
ps fait tout cela, exemple ps auxf, et dans mon cas tout etait à quasi
< 1% CPU d'ou le mystere ! Bien sur je regrette de n'avoir pas
lancer top qui aurait peut etre vu qq chose mais je l'utilise jamais.
Bah non, il ne donne pas la répartition des temps d'utilisation.
Je viens de vérifier, et ça tombe bien, POSIX dit la même chose.
Il y a peut-être d'autres options qui font celà, mais celles que
tu donnes sont censé respecter POSIX. Si c'est le cas, sur ta distrib,
dépèche toi d'en installer une autre !
D'après le mail que tu as posté (erreurs disques), si top
ne te dis pas que ton CPU passe la majeure partie de son temps
à attendre des IO, alors soit ton installation est rootkitée,
soit ta distrib est buggée...
D'ailleurs, avec un load-average comme celui-là,
load average: 3.53, 2.93, 1.65
il est strictement impossible que le CPU soit occupé à moins de 1%
en moyenne...
On Mon, 01 Dec 2003 00:02:07 +0100, interstellar overdrive wrote:
J. Mayer wrote:
Dans ce cas, top te dira si le PC passe son temps dans le kernel, si il est bloqué sur des IO... Cpu(s): 11.3% us, 8.5% sy, 0.0% ni, 80.2% id, 0.0% wa, 0.0% hi, 0.0% si Ca donne 11.3% utilisé en mode user (les process), 8.5% par le system 0% en nice 80.2% idle (il ne fait rien). 0% en wait (bloqué sur des IO).
ps fait tout cela, exemple ps auxf, et dans mon cas tout etait à quasi < 1% CPU d'ou le mystere ! Bien sur je regrette de n'avoir pas lancer top qui aurait peut etre vu qq chose mais je l'utilise jamais.
Bah non, il ne donne pas la répartition des temps d'utilisation. Je viens de vérifier, et ça tombe bien, POSIX dit la même chose. Il y a peut-être d'autres options qui font celà, mais celles que tu donnes sont censé respecter POSIX. Si c'est le cas, sur ta distrib, dépèche toi d'en installer une autre !
D'après le mail que tu as posté (erreurs disques), si top ne te dis pas que ton CPU passe la majeure partie de son temps à attendre des IO, alors soit ton installation est rootkitée, soit ta distrib est buggée...
D'ailleurs, avec un load-average comme celui-là, load average: 3.53, 2.93, 1.65 il est strictement impossible que le CPU soit occupé à moins de 1% en moyenne...
interstellar overdrive
J. Mayer wrote:
D'après le mail que tu as posté (erreurs disques), si top ne te dis pas que ton CPU passe la majeure partie de son temps à attendre des IO, alors soit ton installation est rootkitée, soit ta distrib est buggée...
Non, c'est comme pour l'utilisation des ressources par X11; top, ps, xload, etc... souvent ne donne pas une image réelle de ce qui se passe.
D'ailleurs, avec un load-average comme celui-là, load average: 3.53, 2.93, 1.65 il est strictement impossible que le CPU soit occupé à moins de 1% en moyenne...
Je n'ai pas dis le contraire!
J. Mayer wrote:
D'après le mail que tu as posté (erreurs disques), si top
ne te dis pas que ton CPU passe la majeure partie de son temps
à attendre des IO, alors soit ton installation est rootkitée,
soit ta distrib est buggée...
Non, c'est comme pour l'utilisation des ressources par X11;
top, ps, xload, etc... souvent ne donne pas une image réelle
de ce qui se passe.
D'ailleurs, avec un load-average comme celui-là,
load average: 3.53, 2.93, 1.65
il est strictement impossible que le CPU soit occupé à moins de 1%
en moyenne...
D'après le mail que tu as posté (erreurs disques), si top ne te dis pas que ton CPU passe la majeure partie de son temps à attendre des IO, alors soit ton installation est rootkitée, soit ta distrib est buggée...
Non, c'est comme pour l'utilisation des ressources par X11; top, ps, xload, etc... souvent ne donne pas une image réelle de ce qui se passe.
D'ailleurs, avec un load-average comme celui-là, load average: 3.53, 2.93, 1.65 il est strictement impossible que le CPU soit occupé à moins de 1% en moyenne...
Je n'ai pas dis le contraire!
Emmanuel Florac
Le Mon, 01 Dec 2003 00:31:44 +0100, interstellar overdrive écrivait:
Arrgg!!!
En effet. Tu as fait des backups, naturellement?
-- Dix grammes d'abstraction valent des tonnes de bricolage. Loi de Booker.
Le Mon, 01 Dec 2003 00:31:44 +0100, interstellar overdrive écrivait:
Arrgg!!!
En effet. Tu as fait des backups, naturellement?
--
Dix grammes d'abstraction valent des tonnes de bricolage.
Loi de Booker.
Le Mon, 01 Dec 2003 00:31:44 +0100, interstellar overdrive écrivait:
Arrgg!!!
En effet. Tu as fait des backups, naturellement?
-- Dix grammes d'abstraction valent des tonnes de bricolage. Loi de Booker.
interstellar overdrive
Emmanuel Florac wrote:
Le Mon, 01 Dec 2003 00:31:44 +0100, interstellar overdrive écrivait:
Arrgg!!!
En effet. Tu as fait des backups, naturellement?
Oui, d'ailleur se probleme est apparu apres une sauvegarde! J'ai fait fsck -f /dev/... et n'ai trouvé aucun probleme. Depuis 24h pas de probleme visible via syslog mais j'ai ca au boot:
Le Mon, 01 Dec 2003 00:31:44 +0100, interstellar overdrive écrivait:
Arrgg!!!
En effet. Tu as fait des backups, naturellement?
Oui, d'ailleur se probleme est apparu apres une sauvegarde!
J'ai fait fsck -f /dev/... et n'ai trouvé aucun probleme.
Depuis 24h pas de probleme visible via syslog mais j'ai
ca au boot:
Le Mon, 01 Dec 2003 00:31:44 +0100, interstellar overdrive écrivait:
Arrgg!!!
En effet. Tu as fait des backups, naturellement?
Oui, d'ailleur se probleme est apparu apres une sauvegarde! J'ai fait fsck -f /dev/... et n'ai trouvé aucun probleme. Depuis 24h pas de probleme visible via syslog mais j'ai ca au boot:
