problème de charge disque

Gaëtan PERRIER

01/05/2015 à 15:10

Le Fri, 1 May 2015 14:40:01 +0200
Gaëtan PERRIER a écrit:

Le Fri, 1 May 2015 14:33:27 +0200
Gaëtan PERRIER a écrit:

> Le Fri, 1 May 2015 14:27:50 +0200
> Gaëtan PERRIER a écrit:
>
> > De toute façon elle ne semble pas prise en compte car le résultat de
> > mount ne la présente pas ... (voir pj)
> >
>
> Je confirme. CONFIG_EXT4_FS_XATTR n'est pas activé dans les noyaux
> debian ...
>

Par contre dans les noyaux 3.2 de wheezy cette option était présente ...
Je me demande à partir de quand elle a été retirée et pourquoi ?

Bon en fait l'option a été supprimée et c'est activé par défaut d ans le noyau
maintenant:
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit /?id�9da1084458246d2e29dd921c2012c177000e96

Gaëtan

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/

Gaëtan PERRIER

01/05/2015 à 15:20

Le Fri, 01 May 2015 14:48:20 +0200
mireero a écrit:

On 05/01/2015 02:30 PM, Gaëtan PERRIER wrote:
>> Tu peux aussi faire des tests d'écriture sur chacun de tes disques
>> >pour te faire une comparaison?
> De quelle manière ?

Peut-être hdparm -tT /dev/disk

ça j'ai déjà fait et je n'ai rien vu d'anormal:

hdparm -tT /dev/sdb

/dev/sdb:
Timing cached reads: 22350 MB in 2.00 seconds = 11184.15 MB/sec
Timing buffered disk reads: 574 MB in 3.00 seconds = 191.02 MB/sec

et dd if=/dev/zero of=/dossier/sur/le/disque bs=(au choix).

Oui mais tu mesures comment ?

Gaëtan

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/

Sylvain L. Sauvage

01/05/2015 à 16:20

Le vendredi 1 mai 2015, 15:13:49 GaÃ«tan PERRIER a Ã©crit :

[â¦]
> et dd if=/dev/zero of=/dossier/sur/le/disque bs=(au choix).

Oui mais tu mesures comment ?

Une fois fini, dd tâindique le nombre de blocs et dâo ctets
Ã©crits, le temps Ã©coulÃ© et le dÃ©bit.

De lÃ©gers problÃ¨mes avec la commande indiquÃ©e :

1. il nây a pas dâoption count, donc Ã§a ne termine pas. Ãa peut
se dÃ©fendre si on veut voir ce quâil se passe sur le disqu e
pendant que dd fait son boulotâ¦

2. La source est virtuelle, donc on ne teste pas la lecture.

3. La sortie est un fichier plein de zÃ©ros, donc, sur un systÃ¨ me
de fichiers moderne, il nây a rien dâÃ©crit sur le disque (Ã part
une entrÃ©e qui dit que le fichier est plein de X zÃ©ros).

En rÃ©sumÃ© : Ã§a ne lit rien, Ã§a nâÃ©cr it rien et Ã§a ne sâarrÃªte
pas.

Pour ton problÃ¨me, tu as vÃ©rifiÃ©/modifiÃ© les para mÃ¨tres hdparm
(mise en veilleâ¦) ?

--
Sylvain Sauvage

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/

mireero

01/05/2015 à 16:30

On 05/01/2015 03:20 PM, Gaëtan PERRIER wrote:

Le Fri, 01 May 2015 14:48:20 +0200
mireero a écrit:

On 05/01/2015 02:30 PM, Gaëtan PERRIER wrote:
Tu peux aussi faire des tests d'écriture sur chacun de tes disques
pour te faire une comparaison?

De quelle manière ?

Peut-être hdparm -tT /dev/disk

ça j'ai déjà fait et je n'ai rien vu d'anormal:

hdparm -tT /dev/sdb

/dev/sdb:
Timing cached reads: 22350 MB in 2.00 seconds = 11184.15 MB/sec
Timing buffered disk reads: 574 MB in 3.00 seconds = 191.02 MB/sec

et dd if=/dev/zero of=/dossier/sur/le/disque bs=(au choix).

Oui mais tu mesures comment ?

Gaëtan

Par exemple:
time dd if=/dev/zero of=/disque/fichier bs=1M count0

--
mireero

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/55438752$0$3332$

Ga

01/05/2015 à 16:30

Le Fri, 01 May 2015 16:14:07 +0200
"Sylvain L. Sauvage" a écrit:

Pour ton problème, tu as vérifié/modifié les paramètres hdparm
(mise en veille…) ?

Euh je vois mal le disque se mettre en veille alors qu'il est chargé à 100%,
non ?
Mais j'ai regardé et les deux disques sont à 254. Donc mise en veille
désactivée.

Gaëtan

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/

Sylvain L. Sauvage

01/05/2015 à 16:40

Le vendredi 1 mai 2015, 16:22:36 GaÃ«tan PERRIER a Ã©crit :

Le Fri, 01 May 2015 16:14:07 +0200

"Sylvain L. Sauvage" a Ã©crit:
> Pour ton problÃ¨me, tu as vÃ©rifiÃ©/modifiÃ© les paramÃ¨tres
> hdparm>
> (mise en veilleâ¦) ?

Euh je vois mal le disque se mettre en veille alors qu'il est
chargÃ© Ã 100%, non ?

Ma faute, jâavais retenu le cas des applications qui mettent
du temps Ã se fermer (fermeture â sauvegarde de la conf. â
redÃ©marrage du disque si spin-down â dÃ©lai)â¦

Mais j'ai regardÃ© et les deux disques sont Ã 254. Donc mise en
veille dÃ©sactivÃ©e.

â¦ mais câest pas plus mal de vÃ©rifier : il aurai t pu y avoir
plusieurs problÃ¨mes en mÃªme temps.

Pour revenir sur les tests en lecture/Ã©criture, il y a
bonnie++ qui est censÃ© les faire correctement.
Si les dÃ©bits sont corrects, câest quâil y a aut re chose entre
les applications qui coincent et les E/S.

--
Sylvain Sauvage

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/

mireero

01/05/2015 à 16:50

et dd if=/dev/zero of=/dossier/sur/le/disque bs=(au choix).

Ah, j'oubliais, la lecture:

time dd if=/dev/sdb (ou /disk/file) of=/dev/null bs=4M count%

J'avais vu un message par ici (il y a déjà quelque temps) qui
conseillait d'ajouter une option à "dd" pour être plus précis mais je me
suis pas attardé et c'est oublié.

--
mireero

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/55438ba5$0$3352$

Francois Lafont

01/05/2015 à 16:50

Bonjour Gaëtan,

Bon je ne suis vraiment pas un expert dans ce domaine mais bon, je tente
des remarques quand même. C'est le genre de problème pas facile à résoudre.

Déjà pour être sûr que c'est bien au niveau des I/O disque que ça coince,
vérifie quand même les « I/O wait » de ton CPU (les moments où le CPU est
forcé d'être oisif car il doit attendre que les I/O se terminent) durant
une période d'activité et de lenteur de ton système. Tu peux le voir par
exemple avec la commande top au niveau du champ « wa » de l'activité CPU.
Parce que si, au moment où tu utilises gedit, tu constates des lenteurs
et une activité à 100% d'un disque mais que par ailleurs ton CPU n'a pas
d'I/O wait alors c'est que ce n'est pas au niveau du disque que ça coince
Ce que je veux dire c'est que c'est pas forcément parce que le disque est
utilisé à 100% que c'est lui qui ralentit le système (bon certes c'est peu
probable, je te l'accorde).

Ensuite, si c'est bien une lenteur au niveau des disques, alors pour cibler
un peu plus le coupable tu peux utiliser la commande suivante lors d'une
période de lenteurs :

# Tu indiques tous tes disques, j'ai cru comprendre que tu en avais 2.
# Le « 2 » en argument ci-dessous signifie un rafraîchissement de l'affichage
# toutes les 2 secondes.
# (je ne sais plus dans quel paquet se trouve cette commande, désolé)
iostat -t -x -m -p /dev/sda,/dev/sdb 2

Tu regardes la partition pour laquelle la colonne « await » est la plus
élevée. Je pense que tu l'as déjà fait, mais vérifie bien avec iotop par
exemple qu'il n'y pas un process en train de bourriner des I/O à ton
insu.

Enfin tu peux tester le débit en écriture sur tes disques avec par exemple :

# Ici ça écrit 100 fois un 1 Méga en utilisant le cache du filesystem (et
# donc la RAM), ce qui correspond au cas réel par défaut.
dd if=/dev/zero of=/destination/foo bs=1M count=1OO

# La même chose mais sans passer par le cache du filesystem afin
# de voir vraiment le débit en écriture du disque.
dd if=/dev/zero of=/destination/foo bs=1M count=1OO oflag=direct

À faire avec comme destination un fichier se trouvant dans la partition
suspecte. En vérité dd ne correspond pas vraiment à une écriture « classique »
car c'est une écriture séquentiel ce qui n'est en général pas le cas dans la
vraie vie mais bon, c'est déjà un test rapide à faire.

Un truc que je tenterais aussi, c'est de « stracer » une petite commande
(typiquement pas Virtualbox) qui provoque les ralentissements que tu constates.
Par exemple avec gedit si j'ai bien suivi :

strace -t -f gedit ... 2> /tmp/log.txt

Avec -t, tu auras la date (à la seconde près) en face de chaque ligne ce
qui te permettra de voir les lignes correspondant à la période de lenteur.
Bon, la sortie de strace c'est pas jojo à regarder mais parfois ça peut
aider à cibler le problème.

--
François Lafont

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/mi03bo$l3f$

Bonjour Gaëtan,

Bon je ne suis vraiment pas un expert dans ce domaine mais bon, je tente
des remarques quand même. C'est le genre de problème pas facile à résoudre.

Déjà pour être sûr que c'est bien au niveau des I/O disque que ça coince,
vérifie quand même les « I/O wait » de ton CPU (les moments où le CPU est
forcé d'être oisif car il doit attendre que les I/O se terminent) durant
une période d'activité et de lenteur de ton système. Tu peux le voir par
exemple avec la commande top au niveau du champ « wa » de l'activité CPU.
Parce que si, au moment où tu utilises gedit, tu constates des lenteurs
et une activité à 100% d'un disque mais que par ailleurs ton CPU n'a pas
d'I/O wait alors c'est que ce n'est pas au niveau du disque que ça coince
Ce que je veux dire c'est que c'est pas forcément parce que le disque est
utilisé à 100% que c'est lui qui ralentit le système (bon certes c'est peu
probable, je te l'accorde).

Ensuite, si c'est bien une lenteur au niveau des disques, alors pour cibler
un peu plus le coupable tu peux utiliser la commande suivante lors d'une
période de lenteurs :

# Tu indiques tous tes disques, j'ai cru comprendre que tu en avais 2.
# Le « 2 » en argument ci-dessous signifie un rafraîchissement de l'affichage
# toutes les 2 secondes.
# (je ne sais plus dans quel paquet se trouve cette commande, désolé)
iostat -t -x -m -p /dev/sda,/dev/sdb 2

Tu regardes la partition pour laquelle la colonne « await » est la plus
élevée. Je pense que tu l'as déjà fait, mais vérifie bien avec iotop par
exemple qu'il n'y pas un process en train de bourriner des I/O à ton
insu.

Enfin tu peux tester le débit en écriture sur tes disques avec par exemple :

# Ici ça écrit 100 fois un 1 Méga en utilisant le cache du filesystem (et
# donc la RAM), ce qui correspond au cas réel par défaut.
dd if=/dev/zero of=/destination/foo bs=1M count=1OO

# La même chose mais sans passer par le cache du filesystem afin
# de voir vraiment le débit en écriture du disque.
dd if=/dev/zero of=/destination/foo bs=1M count=1OO oflag=direct

À faire avec comme destination un fichier se trouvant dans la partition
suspecte. En vérité dd ne correspond pas vraiment à une écriture « classique »
car c'est une écriture séquentiel ce qui n'est en général pas le cas dans la
vraie vie mais bon, c'est déjà un test rapide à faire.

Un truc que je tenterais aussi, c'est de « stracer » une petite commande
(typiquement pas Virtualbox) qui provoque les ralentissements que tu constates.
Par exemple avec gedit si j'ai bien suivi :

strace -t -f gedit ... 2> /tmp/log.txt

Avec -t, tu auras la date (à la seconde près) en face de chaque ligne ce
qui te permettra de voir les lignes correspondant à la période de lenteur.
Bon, la sortie de strace c'est pas jojo à regarder mais parfois ça peut
aider à cibler le problème.

--
François Lafont

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/mi03bo$l3f$1@ger.gmane.org

Vous avez filtré cet utilisateur ! Consultez son message

Bonjour Gaëtan,

Bon je ne suis vraiment pas un expert dans ce domaine mais bon, je tente
des remarques quand même. C'est le genre de problème pas facile à résoudre.

Déjà pour être sûr que c'est bien au niveau des I/O disque que ça coince,
vérifie quand même les « I/O wait » de ton CPU (les moments où le CPU est
forcé d'être oisif car il doit attendre que les I/O se terminent) durant
une période d'activité et de lenteur de ton système. Tu peux le voir par
exemple avec la commande top au niveau du champ « wa » de l'activité CPU.
Parce que si, au moment où tu utilises gedit, tu constates des lenteurs
et une activité à 100% d'un disque mais que par ailleurs ton CPU n'a pas
d'I/O wait alors c'est que ce n'est pas au niveau du disque que ça coince
Ce que je veux dire c'est que c'est pas forcément parce que le disque est
utilisé à 100% que c'est lui qui ralentit le système (bon certes c'est peu
probable, je te l'accorde).

Ensuite, si c'est bien une lenteur au niveau des disques, alors pour cibler
un peu plus le coupable tu peux utiliser la commande suivante lors d'une
période de lenteurs :

# Tu indiques tous tes disques, j'ai cru comprendre que tu en avais 2.
# Le « 2 » en argument ci-dessous signifie un rafraîchissement de l'affichage
# toutes les 2 secondes.
# (je ne sais plus dans quel paquet se trouve cette commande, désolé)
iostat -t -x -m -p /dev/sda,/dev/sdb 2

Tu regardes la partition pour laquelle la colonne « await » est la plus
élevée. Je pense que tu l'as déjà fait, mais vérifie bien avec iotop par
exemple qu'il n'y pas un process en train de bourriner des I/O à ton
insu.

Enfin tu peux tester le débit en écriture sur tes disques avec par exemple :

# Ici ça écrit 100 fois un 1 Méga en utilisant le cache du filesystem (et
# donc la RAM), ce qui correspond au cas réel par défaut.
dd if=/dev/zero of=/destination/foo bs=1M count=1OO

# La même chose mais sans passer par le cache du filesystem afin
# de voir vraiment le débit en écriture du disque.
dd if=/dev/zero of=/destination/foo bs=1M count=1OO oflag=direct

À faire avec comme destination un fichier se trouvant dans la partition
suspecte. En vérité dd ne correspond pas vraiment à une écriture « classique »
car c'est une écriture séquentiel ce qui n'est en général pas le cas dans la
vraie vie mais bon, c'est déjà un test rapide à faire.

Un truc que je tenterais aussi, c'est de « stracer » une petite commande
(typiquement pas Virtualbox) qui provoque les ralentissements que tu constates.
Par exemple avec gedit si j'ai bien suivi :

strace -t -f gedit ... 2> /tmp/log.txt

Avec -t, tu auras la date (à la seconde près) en face de chaque ligne ce
qui te permettra de voir les lignes correspondant à la période de lenteur.
Bon, la sortie de strace c'est pas jojo à regarder mais parfois ça peut
aider à cibler le problème.

--
François Lafont

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/mi03bo$l3f$

Gaëtan PERRIER

01/05/2015 à 17:00

Le Fri, 01 May 2015 16:41:59 +0200
Francois Lafont a écrit:

Déjà pour être sûr que c'est bien au niveau des I/O disque que ça coince,
vérifie quand même les « I/O wait » de ton CPU [...] durant
une période d'activité et de lenteur de ton système. Tu peux le voi r par
exemple avec la commande top au niveau du champ « wa » de l'activit é CPU.
Parce que si, au moment où tu utilises gedit, tu constates des lenteurs
et une activité à 100% d'un disque mais que par ailleurs ton CPU n'a pas
d'I/O wait alors c'est que ce n'est pas au niveau du disque que ça coin ce

Je viens de faire le test en fermant gthumb et j'ai bien les wa qui montent
fortement (>30).

Ensuite, si c'est bien une lenteur au niveau des disques, alors pour cibl er
un peu plus le coupable tu peux utiliser la commande suivante lors d'une
période de lenteurs :

# Tu indiques tous tes disques, j'ai cru comprendre que tu en avais 2.
# Le « 2 » en argument ci-dessous signifie un rafraîchissement de
# l'affichage toutes les 2 secondes.
# (je ne sais plus dans quel paquet se trouve cette commande, désol é)
iostat -t -x -m -p /dev/sda,/dev/sdb 2

Tu regardes la partition pour laquelle la colonne « await » est la pl us
élevée. Je pense que tu l'as déjà fait, mais vérifie bien avec iotop par
exemple qu'il n'y pas un process en train de bourriner des I/O à ton
insu.

Je vois beaucoup d'await (>300 voir même 1000) sur sdb5 et 7 soit /home e t /tmp
quand je ferme gthumb par exemple.

Gaëtan

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/

Francois Lafont

01/05/2015 à 17:30

Le 01/05/2015 16:14, Sylvain L. Sauvage a écrit :

et dd if=/dev/zero of=/dossier/sur/le/disque bs=(au choix).

[...]

3. La sortie est un fichier plein de zéros, donc, sur un système
de fichiers moderne, il n’y a rien d’écrit sur le disque (à part
une entrée qui dit que le fichier est plein de X zéros).

Tu es sûr de ça ? Par exemple, sur ma Debian Wheezy j'ai :

-------------------------------------------------
~$ echo Salut > /tmp/out

~$ od -Ad -x /tmp/out
0000000 6153 756c 0a74
0000006

~$ dd if=/dev/zero of=/tmp/out bs0c count=1
1+0 enregistrements lus
1+0 enregistrements écrits
100 octets (100 B) copiés, 9,6205e-05 s, 1,0 MB/s

~$ od -Ad -v -x /tmp/out
0000000 0000 0000 0000 0000 0000 0000 0000 0000
0000016 0000 0000 0000 0000 0000 0000 0000 0000
0000032 0000 0000 0000 0000 0000 0000 0000 0000
0000048 0000 0000 0000 0000 0000 0000 0000 0000
0000064 0000 0000 0000 0000 0000 0000 0000 0000
0000080 0000 0000 0000 0000 0000 0000 0000 0000
0000096 0000 0000
0000100
-------------------------------------------------

sachant que /tmp se trouve sur ma partition racine qui est en ext4.
À moins que ext4 ne soit peut-être pas assez « moderne » pour supporter
la fonctionnalité dont tu parles ? Ou alors c'est la commande od qui
ne m'indique pas le contenu du fichier tel qu'il est réellement ?

--
François Lafont

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/mi05vv$2f9$

problème de charge disque

10 réponses

Veuillez sélectionner un problème