Bref, pour en revenir à ton problème, je trouve quand même curieux que
du jour au lendemain tu te retrouves avec des perfs pourries comme ça.
J'ai du mal à imaginer un problème matériel (mais j'ai peut-être tort)
et je pense que si tu avais fait des modifs particulières au niveau des
disques (genre options de montages etc.) tu n'aurais pas manqué de nous
le signaler.
Non rien fait de particulier. Au début j'ai commencé à m'apercevoir que
tracker monopolisait beaucoup de temps sur la machine. Je l'ai mis en cause (y
a eu un fil sur la liste à ce sujet). Ensuite je me suis décidé à le virer
mais même si c'était mieux j'avais toujours des lags.
N'y aurait-il pas un process qui tourne en arrière plan et qui sollicite
ton disque sans arrêt de sorte que ça te plombe tes I/O ?
Non le disque ne semble pas être sollicité en permanence mais régulièrement
iotop me montre kworker, atop ne montre pas une charge dessus quand je ne fais
rien. De même pour iostat.
Avant j'avais 3 partitions sur ce disque (home, tmp, srv). Cette nuit j'ai
passé tmp en tmpfs. Il ne reste donc que home et srv.
Sur srv j'ai juste un petit serveur ftp accessible localement uniquement.
Donc il ne reste des accès que sur home (confirmé par iostat)
Pour écarter ce genre d'hypothèse, perso,
je pense qu'à ta place je redémarrerais le système en mode « recovery »
avec juste une console root (le truc le plus minimaliste possible quoi),
ensuite je démonterais *toutes* les partitions du disque suspect, puis
je remonterais uniquement la partition /home mais au niveau d'un répertoire
différent de /home justement (par exemple /home_tmp) puis je tenterais un
nouveau test bonnie++ (exactement le même que celui que tu as déjà effectué
précédemment).
Pourquoi pas. Je vais essayer des que je peux.
D'ailleurs tu lances bonnie++ avec quelles options ?
Bref, pour en revenir à ton problème, je trouve quand même curieux que
du jour au lendemain tu te retrouves avec des perfs pourries comme ça.
J'ai du mal à imaginer un problème matériel (mais j'ai peut-être tort)
et je pense que si tu avais fait des modifs particulières au niveau des
disques (genre options de montages etc.) tu n'aurais pas manqué de nous
le signaler.
Non rien fait de particulier. Au début j'ai commencé à m'apercevoir que
tracker monopolisait beaucoup de temps sur la machine. Je l'ai mis en cause (y
a eu un fil sur la liste à ce sujet). Ensuite je me suis décidé à le virer
mais même si c'était mieux j'avais toujours des lags.
N'y aurait-il pas un process qui tourne en arrière plan et qui sollicite
ton disque sans arrêt de sorte que ça te plombe tes I/O ?
Non le disque ne semble pas être sollicité en permanence mais régulièrement
iotop me montre kworker, atop ne montre pas une charge dessus quand je ne fais
rien. De même pour iostat.
Avant j'avais 3 partitions sur ce disque (home, tmp, srv). Cette nuit j'ai
passé tmp en tmpfs. Il ne reste donc que home et srv.
Sur srv j'ai juste un petit serveur ftp accessible localement uniquement.
Donc il ne reste des accès que sur home (confirmé par iostat)
Pour écarter ce genre d'hypothèse, perso,
je pense qu'à ta place je redémarrerais le système en mode « recovery »
avec juste une console root (le truc le plus minimaliste possible quoi),
ensuite je démonterais *toutes* les partitions du disque suspect, puis
je remonterais uniquement la partition /home mais au niveau d'un répertoire
différent de /home justement (par exemple /home_tmp) puis je tenterais un
nouveau test bonnie++ (exactement le même que celui que tu as déjà effectué
précédemment).
Pourquoi pas. Je vais essayer des que je peux.
D'ailleurs tu lances bonnie++ avec quelles options ?
Bref, pour en revenir à ton problème, je trouve quand même curieux que
du jour au lendemain tu te retrouves avec des perfs pourries comme ça.
J'ai du mal à imaginer un problème matériel (mais j'ai peut-être tort)
et je pense que si tu avais fait des modifs particulières au niveau des
disques (genre options de montages etc.) tu n'aurais pas manqué de nous
le signaler.
Non rien fait de particulier. Au début j'ai commencé à m'apercevoir que
tracker monopolisait beaucoup de temps sur la machine. Je l'ai mis en cause (y
a eu un fil sur la liste à ce sujet). Ensuite je me suis décidé à le virer
mais même si c'était mieux j'avais toujours des lags.
N'y aurait-il pas un process qui tourne en arrière plan et qui sollicite
ton disque sans arrêt de sorte que ça te plombe tes I/O ?
Non le disque ne semble pas être sollicité en permanence mais régulièrement
iotop me montre kworker, atop ne montre pas une charge dessus quand je ne fais
rien. De même pour iostat.
Avant j'avais 3 partitions sur ce disque (home, tmp, srv). Cette nuit j'ai
passé tmp en tmpfs. Il ne reste donc que home et srv.
Sur srv j'ai juste un petit serveur ftp accessible localement uniquement.
Donc il ne reste des accès que sur home (confirmé par iostat)
Pour écarter ce genre d'hypothèse, perso,
je pense qu'à ta place je redémarrerais le système en mode « recovery »
avec juste une console root (le truc le plus minimaliste possible quoi),
ensuite je démonterais *toutes* les partitions du disque suspect, puis
je remonterais uniquement la partition /home mais au niveau d'un répertoire
différent de /home justement (par exemple /home_tmp) puis je tenterais un
nouveau test bonnie++ (exactement le même que celui que tu as déjà effectué
précédemment).
Pourquoi pas. Je vais essayer des que je peux.
D'ailleurs tu lances bonnie++ avec quelles options ?
[â¦]
Merci pour les explications. Je comprends l'idée mais j'avoue
ne pas trop comprendre en quoi une lecture nécessite un
travail (un calcul) du CPU en fait.
[â¦]
Merci pour les explications. Je comprends l'idée mais j'avoue
ne pas trop comprendre en quoi une lecture nécessite un
travail (un calcul) du CPU en fait.
[â¦]
Merci pour les explications. Je comprends l'idée mais j'avoue
ne pas trop comprendre en quoi une lecture nécessite un
travail (un calcul) du CPU en fait.
Si tu as un disque de libre, avec l'espace disque suffisant, fait un
dd du disque suspecté vers le nouveau.
Tu pourras alors réellement incriminer ton disque dur après test?
Si tu as un disque de libre, avec l'espace disque suffisant, fait un
dd du disque suspecté vers le nouveau.
Tu pourras alors réellement incriminer ton disque dur après test?
Si tu as un disque de libre, avec l'espace disque suffisant, fait un
dd du disque suspecté vers le nouveau.
Tu pourras alors réellement incriminer ton disque dur après test?
Le Sun, 3 May 2015 00:59:37 +0200
honeyshell a écrit:
> Si tu as un disque de libre, avec l'espace disque suffisant, fait un
> dd du disque suspecté vers le nouveau.
> Tu pourras alors réellement incriminer ton disque dur après test?
>
Malheureusement je n'ai pas de disque libre sous la main.
Gaëtan
Le Sun, 3 May 2015 00:59:37 +0200
honeyshell <honeyshell@honeyshell.com> a écrit:
> Si tu as un disque de libre, avec l'espace disque suffisant, fait un
> dd du disque suspecté vers le nouveau.
> Tu pourras alors réellement incriminer ton disque dur après test?
>
Malheureusement je n'ai pas de disque libre sous la main.
Gaëtan
Le Sun, 3 May 2015 00:59:37 +0200
honeyshell a écrit:
> Si tu as un disque de libre, avec l'espace disque suffisant, fait un
> dd du disque suspecté vers le nouveau.
> Tu pourras alors réellement incriminer ton disque dur après test?
>
Malheureusement je n'ai pas de disque libre sous la main.
Gaëtan
[â¦]
Y a quand même un truc de bizarre. Si je lance vim dans
terminal il s'ouvre instantanément. Si je lance gvim depuis
ce même terminal, celui-ce met très longtemps avant de
s'ouvrir et j'ai l'occupation disque à 100%. La seule
différence c'est l'interface graphique de gvim. Pour le reste
les mêmes fichiers de confs et les mêmes plugins sont
chargés. Ãa pourrait vouloir donc dire que lag viendrait du
système graphique ? Mais dans ce cas les résultats de bonni e
ne devrait pas être si mauvais ? J'y comprends rien en fait
... :)
[â¦]
Y a quand même un truc de bizarre. Si je lance vim dans
terminal il s'ouvre instantanément. Si je lance gvim depuis
ce même terminal, celui-ce met très longtemps avant de
s'ouvrir et j'ai l'occupation disque à 100%. La seule
différence c'est l'interface graphique de gvim. Pour le reste
les mêmes fichiers de confs et les mêmes plugins sont
chargés. Ãa pourrait vouloir donc dire que lag viendrait du
système graphique ? Mais dans ce cas les résultats de bonni e
ne devrait pas être si mauvais ? J'y comprends rien en fait
... :)
[â¦]
Y a quand même un truc de bizarre. Si je lance vim dans
terminal il s'ouvre instantanément. Si je lance gvim depuis
ce même terminal, celui-ce met très longtemps avant de
s'ouvrir et j'ai l'occupation disque à 100%. La seule
différence c'est l'interface graphique de gvim. Pour le reste
les mêmes fichiers de confs et les mêmes plugins sont
chargés. Ãa pourrait vouloir donc dire que lag viendrait du
système graphique ? Mais dans ce cas les résultats de bonni e
ne devrait pas être si mauvais ? J'y comprends rien en fait
... :)
Le dimanche 3 mai 2015, 04:46:04 Gaëtan PERRIER a écrit :
>[…]
> Y a quand même un truc de bizarre. Si je lance vim dans
> terminal il s'ouvre instantanément. Si je lance gvim depuis
> ce même terminal, celui-ce met très longtemps avant de
> s'ouvrir et j'ai l'occupation disque à 100%. La seule
> différence c'est l'interface graphique de gvim. Pour le reste
> les mêmes fichiers de confs et les mêmes plugins sont
> chargés. Ça pourrait vouloir donc dire que lag viendrait du
> système graphique ? Mais dans ce cas les résultats de bonnie
> ne devrait pas être si mauvais ? J'y comprends rien en fait
> ... :)
Regarde la quantité de fichiers ouverts par l’un et l’autre
avec 'strace -e open gvim'.
Les bibliothèques graphiques doivent être assez nombreuses. En
plus, pour chaque bibliothèque, ld peut essayer plusieurs
chemins avant de trouver la bonne (notamment si tu as un
LD_LIBRARY_PATH).
En tout cas, ça peut être une piste : le problème ne vient pas
forcément du fait que ces bibs et fichiers sont du système
graphique mais qu’elles sont placées à un certain endroit.
Euh, au fait, ton système (/usr) n’était pas censé être sur un
SSD ?
Le dimanche 3 mai 2015, 04:46:04 Gaëtan PERRIER a écrit :
>[…]
> Y a quand même un truc de bizarre. Si je lance vim dans
> terminal il s'ouvre instantanément. Si je lance gvim depuis
> ce même terminal, celui-ce met très longtemps avant de
> s'ouvrir et j'ai l'occupation disque à 100%. La seule
> différence c'est l'interface graphique de gvim. Pour le reste
> les mêmes fichiers de confs et les mêmes plugins sont
> chargés. Ça pourrait vouloir donc dire que lag viendrait du
> système graphique ? Mais dans ce cas les résultats de bonnie
> ne devrait pas être si mauvais ? J'y comprends rien en fait
> ... :)
Regarde la quantité de fichiers ouverts par l’un et l’autre
avec 'strace -e open gvim'.
Les bibliothèques graphiques doivent être assez nombreuses. En
plus, pour chaque bibliothèque, ld peut essayer plusieurs
chemins avant de trouver la bonne (notamment si tu as un
LD_LIBRARY_PATH).
En tout cas, ça peut être une piste : le problème ne vient pas
forcément du fait que ces bibs et fichiers sont du système
graphique mais qu’elles sont placées à un certain endroit.
Euh, au fait, ton système (/usr) n’était pas censé être sur un
SSD ?
Le dimanche 3 mai 2015, 04:46:04 Gaëtan PERRIER a écrit :
>[…]
> Y a quand même un truc de bizarre. Si je lance vim dans
> terminal il s'ouvre instantanément. Si je lance gvim depuis
> ce même terminal, celui-ce met très longtemps avant de
> s'ouvrir et j'ai l'occupation disque à 100%. La seule
> différence c'est l'interface graphique de gvim. Pour le reste
> les mêmes fichiers de confs et les mêmes plugins sont
> chargés. Ça pourrait vouloir donc dire que lag viendrait du
> système graphique ? Mais dans ce cas les résultats de bonnie
> ne devrait pas être si mauvais ? J'y comprends rien en fait
> ... :)
Regarde la quantité de fichiers ouverts par l’un et l’autre
avec 'strace -e open gvim'.
Les bibliothèques graphiques doivent être assez nombreuses. En
plus, pour chaque bibliothèque, ld peut essayer plusieurs
chemins avant de trouver la bonne (notamment si tu as un
LD_LIBRARY_PATH).
En tout cas, ça peut être une piste : le problème ne vient pas
forcément du fait que ces bibs et fichiers sont du système
graphique mais qu’elles sont placées à un certain endroit.
Euh, au fait, ton système (/usr) n’était pas censé être sur un
SSD ?
Le Sun, 03 May 2015 09:08:13 +0200
"Sylvain L. Sauvage" a écrit:Le dimanche 3 mai 2015, 04:46:04 Gaëtan PERRIER a écrit :[…]
Y a quand même un truc de bizarre. Si je lance vim dans
terminal il s'ouvre instantanément. Si je lance gvim depuis
ce même terminal, celui-ce met très longtemps avant de
s'ouvrir et j'ai l'occupation disque à 100%. La seule
différence c'est l'interface graphique de gvim. Pour le reste
les mêmes fichiers de confs et les mêmes plugins sont
chargés. Ça pourrait vouloir donc dire que lag viendrait du
système graphique ? Mais dans ce cas les résultats de bonnie
ne devrait pas être si mauvais ? J'y comprends rien en fait
... :)
Regarde la quantité de fichiers ouverts par l’un et l’autre
avec 'strace -e open gvim'.
Sauf que tu fais comment pour voir le résultat pour vim ?
avec gvim je fais un strace -e open gvim > /tmp/gvim_strace.txt 2>&1 mais avec
vim je le sens pas bien si je redirige vers un fichier ...
Le Sun, 03 May 2015 09:08:13 +0200
"Sylvain L. Sauvage" <Sylvain.L.Sauvage@free.fr> a écrit:
Le dimanche 3 mai 2015, 04:46:04 Gaëtan PERRIER a écrit :
[…]
Y a quand même un truc de bizarre. Si je lance vim dans
terminal il s'ouvre instantanément. Si je lance gvim depuis
ce même terminal, celui-ce met très longtemps avant de
s'ouvrir et j'ai l'occupation disque à 100%. La seule
différence c'est l'interface graphique de gvim. Pour le reste
les mêmes fichiers de confs et les mêmes plugins sont
chargés. Ça pourrait vouloir donc dire que lag viendrait du
système graphique ? Mais dans ce cas les résultats de bonnie
ne devrait pas être si mauvais ? J'y comprends rien en fait
... :)
Regarde la quantité de fichiers ouverts par l’un et l’autre
avec 'strace -e open gvim'.
Sauf que tu fais comment pour voir le résultat pour vim ?
avec gvim je fais un strace -e open gvim > /tmp/gvim_strace.txt 2>&1 mais avec
vim je le sens pas bien si je redirige vers un fichier ...
Le Sun, 03 May 2015 09:08:13 +0200
"Sylvain L. Sauvage" a écrit:Le dimanche 3 mai 2015, 04:46:04 Gaëtan PERRIER a écrit :[…]
Y a quand même un truc de bizarre. Si je lance vim dans
terminal il s'ouvre instantanément. Si je lance gvim depuis
ce même terminal, celui-ce met très longtemps avant de
s'ouvrir et j'ai l'occupation disque à 100%. La seule
différence c'est l'interface graphique de gvim. Pour le reste
les mêmes fichiers de confs et les mêmes plugins sont
chargés. Ça pourrait vouloir donc dire que lag viendrait du
système graphique ? Mais dans ce cas les résultats de bonnie
ne devrait pas être si mauvais ? J'y comprends rien en fait
... :)
Regarde la quantité de fichiers ouverts par l’un et l’autre
avec 'strace -e open gvim'.
Sauf que tu fais comment pour voir le résultat pour vim ?
avec gvim je fais un strace -e open gvim > /tmp/gvim_strace.txt 2>&1 mais avec
vim je le sens pas bien si je redirige vers un fichier ...
[â¦]
Sauf que tu fais comment pour voir le résultat pour vim ?
avec gvim je fais un strace -e open gvim >
/tmp/gvim_strace.txt 2>&1 mais avec vim je le sens pas bien
si je redirige vers un fichier ...
[â¦]
oui j'ai un LD_LIBRARY_PATH mais il ne contient pas grand
chose. J'ai fait un unset dessus sans résultat. De plus ça
n'expliquerait pas les lags à la fermeture. Je rappelle que
certains logiciels lag à l'ouverture et d'autres à la
fermeture.
[â¦]
Quand je fais le strace sur gvim y a effectivement un moment
ou ça bloque mais c'est à la fin avant d'afficher +++ exite d
with 0 +++ avant ça défile plein gaz puis ça bloque, à §a
affiche la dernière ligne et ça ouvre la fenêtre ... V raiment
bizarre !
> Euh, au fait, ton système (/usr) nâétait pas ce nsé être
> sur un SSD ?
Oui c'est le cas. Pourquoi ?
[â¦]
Sauf que tu fais comment pour voir le résultat pour vim ?
avec gvim je fais un strace -e open gvim >
/tmp/gvim_strace.txt 2>&1 mais avec vim je le sens pas bien
si je redirige vers un fichier ...
[â¦]
oui j'ai un LD_LIBRARY_PATH mais il ne contient pas grand
chose. J'ai fait un unset dessus sans résultat. De plus ça
n'expliquerait pas les lags à la fermeture. Je rappelle que
certains logiciels lag à l'ouverture et d'autres à la
fermeture.
[â¦]
Quand je fais le strace sur gvim y a effectivement un moment
ou ça bloque mais c'est à la fin avant d'afficher +++ exite d
with 0 +++ avant ça défile plein gaz puis ça bloque, à §a
affiche la dernière ligne et ça ouvre la fenêtre ... V raiment
bizarre !
> Euh, au fait, ton système (/usr) nâétait pas ce nsé être
> sur un SSD ?
Oui c'est le cas. Pourquoi ?
[â¦]
Sauf que tu fais comment pour voir le résultat pour vim ?
avec gvim je fais un strace -e open gvim >
/tmp/gvim_strace.txt 2>&1 mais avec vim je le sens pas bien
si je redirige vers un fichier ...
[â¦]
oui j'ai un LD_LIBRARY_PATH mais il ne contient pas grand
chose. J'ai fait un unset dessus sans résultat. De plus ça
n'expliquerait pas les lags à la fermeture. Je rappelle que
certains logiciels lag à l'ouverture et d'autres à la
fermeture.
[â¦]
Quand je fais le strace sur gvim y a effectivement un moment
ou ça bloque mais c'est à la fin avant d'afficher +++ exite d
with 0 +++ avant ça défile plein gaz puis ça bloque, à §a
affiche la dernière ligne et ça ouvre la fenêtre ... V raiment
bizarre !
> Euh, au fait, ton système (/usr) nâétait pas ce nsé être
> sur un SSD ?
Oui c'est le cas. Pourquoi ?
Pour revenir à ton problème, tu peux peut-être creuser un peu
plus avec strace (sans '-e open' qui ne trace que la fonction
open) pour voir ce que fait le programme au moment où il pause.
L’option -r de strace ajoute le temps écoulé depuis l’appel
système précédent (= la ligne du dessus).
Essaie de le faire avec le programme le plus simple possible
(qui a le problème, évidemment ;o) pour ne pas avoir trop de
données à regarder.
Pour revenir à ton problème, tu peux peut-être creuser un peu
plus avec strace (sans '-e open' qui ne trace que la fonction
open) pour voir ce que fait le programme au moment où il pause.
L’option -r de strace ajoute le temps écoulé depuis l’appel
système précédent (= la ligne du dessus).
Essaie de le faire avec le programme le plus simple possible
(qui a le problème, évidemment ;o) pour ne pas avoir trop de
données à regarder.
Pour revenir à ton problème, tu peux peut-être creuser un peu
plus avec strace (sans '-e open' qui ne trace que la fonction
open) pour voir ce que fait le programme au moment où il pause.
L’option -r de strace ajoute le temps écoulé depuis l’appel
système précédent (= la ligne du dessus).
Essaie de le faire avec le programme le plus simple possible
(qui a le problème, évidemment ;o) pour ne pas avoir trop de
données à regarder.