Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Linux Autres OS Linux Debian problème de charge disque

problème de charge disque

59 réponses
Avatar
Gaëtan PERRIER
Bonjour,

J'utilise une debian testing, pour l'instant bloqu=E9e en stable, donc ce n=
'est
pas une installation r=E9cente. Depuis quelques temps je rencontre des prob=
l=E8mes
de charge disque =E0 certains moments. Par exemple quand je ferme certaines
applications (gthumb, gedit, ...) j'ai une forte activ=E9 disque (100%) pen=
dant
quelques secondes. Autre exemple, Virtualbox. Quand celui-ci fait des acc=
=E8s
disques =E7a monte =E0 100% pendant tout le temps d'un download internet, e=
tc.

Bref j'y perds le peu de latin que j'ai ...

Je ne sais pas par quel bout prendre le probl=E8me pour en trouver la cause.
Auriez-vous une id=E9e ?

Ga=EBtan

--
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/20150430231523.9cf5764fd8393631c315d9aa@neuf.fr
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2 3 4 5
Avatar
Gaëtan PERRIER
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/
Avatar
Gaëtan PERRIER
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/
Avatar
Sylvain L. Sauvage
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/
Avatar
mireero
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$
Avatar
Ga
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/
Avatar
Sylvain L. Sauvage
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/
Avatar
mireero

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$
Avatar
Francois Lafont
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$
Avatar
Gaëtan PERRIER
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/
Avatar
Francois Lafont
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$
1 2 3 4 5