Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Performance RAID instable

46 réponses
Avatar
Seb
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

---1155178722-1172973178-1505744315=:30128
Content-Type: TEXT/PLAIN; FORMAT=flowed; CHARSET=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-ID: <alpine.DEB.2.11.1709192101212.3710@af3358511.vc-37-187-30.rh>


Bonjour !


J'utilise Debian depuis une quinzaine d'années, sans problème de RAID
jusqu'à présent. Mon souci actuel est que deux machines qui font chacune
du RAID1 sur deux disques SSD ont des performances disque qui se dégradent
brutalement, sans raison apparente (rien trouvé dans syslog, notamment).
La vitesse du tableau passe, en gros, de 600 Mo/s à 0,5 Mo/s. La
différence est si nette qu'une mesure grossière avec 'dd' suffit à la
mettre en évidence (dd if=/dev/zero of=dd.big bs=1k count=10000).

* La machine à la maison en a été la première victime, dès son
installation sous Debian 8 en janvier 2017 (Debian 8 téléchargée en
janvier aussi). Le PC était neuf, ses disques aussi. (C'est toujours la
version stable de Debian que j'utilise.)

* La machine de bureau, qui donnait entière satisfaction depuis plusieurs
années, a commencé à montrer les mêmes symptômes juste après son passage de
Debian 8 à Debian 9 en juillet 2017. Avant la réinstallation (ce n'était pas
une migration de 8 à 9 ne nécessitant qu'un reboot), la Debian 8 n'était que
partiellement à jour car j'utilise apt-get upgrade mais jamais dist-upgrade. La
version de Debian 8 sur la machine à la maison en janvier 2017 était donc en un
sens plus récente que la version de Debian 8 sur la machine de bureau en
juillet 2017.

* Par ailleurs, j'ai passé deux autres machines en Debian 9 sans rencontrer le
problème, mais elles font toutes deux du RAID6 sur des disques à plateaux.

* Les quatre machines utilisent exclusivement JFS.

Je souligne que même quand les performances deviennent abyssales, les tableaux
RAID fonctionnent. On peut par exemple copier un fichier ('cp').

Redémarrer la machine restaure la performance normale. La performance reste
alors stable pendant plusieurs heures. Puis elle s'écroule, ce qui peut
arriver même quand il n'y a personne devant l'écran, en pleine nuit.

Je joins ci-dessous le résultat des commandes suivantes, lancées sur la machine
de bureau (RAID1 sur sda+sdb):
smartctl -t short /dev/sda
smartctl -l selftest /dev/sda
smartctl -t short /dev/sdb
smartctl -l selftest /dev/sdb

Est-ce que ces comportements vous évoquent des souvenirs, ou des pistes à
creuser ? Comment pourrais-je extraire du système des informations sur
l'origine du problème ? Voyez-vous quels changements intervenus dans la
Debian 8, après la release initiale, pourraient causer ce comportement ?


Merci d'avance pour votre aide !
Seb.

PS: si quelqu'un sait comment régler le p'tit problème suivant, ça me sera
utile aussi: jusqu'à la Debian 8 incluse, quand je faisais un copier-coller
d'une ligne entière depuis un xterm vers un xterm exécutant zsh, la commande
s'exécutait dès l'étape coller. Depuis le passage à Debian 9, la commande
collée apparaît en inverse vidéo, un retour à la ligne a bien été inséré (le
curseur est sur une nouvelle ligne), mais cela ne provoque pas l'exécution de
la commande, il faut encore que j'appuie sur Entrée. J'aimerais bien revenir à
la situation précédente (pas besoin d'appuyer sur Entrée) mais je ne sais pas
ce qu'il faut régler...

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

#smartctl -l selftest /dev/sda
smartctl 6.6 2016-05-31 r4324 [i686-linux-4.9.0-3-686-pae] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours)
LBA_of_first_error
# 1 Short offline Completed without error 00% 17786 -
# 2 Short offline Completed without error 00% 15666 -

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

#smartctl -l selftest /dev/sdb
smartctl 6.6 2016-05-31 r4324 [i686-linux-4.9.0-3-686-pae] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours)
LBA_of_first_error
# 1 Short offline Completed without error 00% 16593 -

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

> cat /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4]
[raid10]
md3 : active raid1 sdb3[1] sda3[0]
951464640 blocks super 1.2 [2/2] [UU]
bitmap: 2/8 pages [8KB], 65536KB chunk

md2 : active raid1 sda1[0] sdb1[1]
20955136 blocks super 1.2 [2/2] [UU]

unused devices: <none>
---1155178722-1172973178-1505744315=:30128--

10 réponses

1 2 3 4 5
Avatar
Seb
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
---1155178722-1084953685-1507191962=:17980
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT
Bonjour Thierry,
Idée de troisième solution à faire en parallèle d'un contournement: se
rapprocher des développeurs du kernel pour signaler qu'il y a
probablement un bug. Je pense qu'il n'y pas plus vraiment de doute
l'existence d'un bug. Peut être que eux, justement, pourront proposer un
contournement fiable en attendant la release du correctif.

C'est faisable. Tu me conseilles de contacter debian-kernel ou lkml ?
Seb.
---1155178722-1084953685-1507191962=:17980--
Avatar
Pascal Hambourg
Le 05/10/2017 à 10:24, Seb a écrit :
Je n'ai pas le courage de relire le fil pour voir si tu l'as déjà fait
: utiliser le noyau 3.16 de Debian 8 sur Debian 9 ?


(...)
Y a-t-il une méthode standard Debian qui me permettrait d'installer sans
trop souffrir le noyau 3.16 sur la Debian 9 ? (Un pointeur vers la bonne
page web m'irait amplement.)

J'essaierais de récupérer directement le .deb du noyau 3.16 de Jessie
depuis <https://packages.debian.org/jessie/linux-image-3.16.0-4-amd64&gt;
(je suppose que l'architecture est amd64) ou depuis une machine sous
Jessie avec apt-get download et de l'installer avec dpkg -i sur Stretch.
Les dépendances devraient être satisfaites.
Sinon, faire comme avec les backports : ajouter les dépôts jessie dans
sources.list et forcer l'installation du paquet de jessie avec apt-get
-t jessie...
Avatar
BERTRAND Jo=c3=abl
Seb a écrit :
Bonjour Pascal,
Je n'ai pas le courage de relire le fil pour voir si tu l'as déjà fait
: utiliser le noyau 3.16 de Debian 8 sur Debian 9 ?

Ah oui, c'est une bonne idée.
Si j'appelle sur une machine en Debian 9
apt-cache search linux-image
je ne vois pas de noyau 3.16 .
Dans la FAQ Debian, chapitre "Debian and the kernel", je ne vois pas de
solution packagée indiquée; d'un autre côté, elle ne mentionne pas non
plus les backports pour avoir, au contraire, un noyau plus récent.
Y a-t-il une méthode standard Debian qui me permettrait d'installer sans
trop souffrir le noyau 3.16 sur la Debian 9 ? (Un pointeur vers la bonne
page web m'irait amplement.)

Avec un init systemV, c'est assez trivial. Avec la grouille
systemd/udev, c'est assez casse-gueule. La seule fois où j'ai dû faire
ça, cela s'est soldé par un échec.
JKB
Avatar
BERTRAND Jo=c3=abl
Seb a écrit :
Bonjour,
Pour finir, je sais obtenir un retour a des performances normales en
vidant le cache :
sync ; echo 2 > /proc/sys/vm/drop_caches
et comme toi, j'ai une nouvelle dégradation violente au bout d'un
certain temps.

Il y a quelques jours, j'ai passé la machine à la maison (Debian 9
stable) sur le noyau 4.12.0-0.bpo.1-686-pae (backports). J'ai continué à
mesurer la performance des disques avec cette nouvelle situation. Voici
le résultat:
https://framapic.org/bFa8E3Zz3aJA/3vFMDsmo5LhF.png

Bon...
Une remarque en passant : je n'ai pas observé ce genre de chose en
amd64 (et sur aucune de mes machines, que ce soit en 4.11 ou 4.12).
Je ne sais pas si tu as indiqué plus haut la taille de la mémoire
installée et le chipset (ou le contrôleur disque). C'est un point à ne
pas négliger d'autant que je vois pae dans le nom du noyau.
Cordialement,
JKB
Avatar
Pascal Hambourg
Le 05/10/2017 à 10:40, Pascal Hambourg a écrit :
Sinon, faire comme avec les backports : ajouter les dépôts jessie dans
sources.list et forcer l'installation du paquet de jessie avec apt-get
-t jessie...

En fait même pas besoin de forcer puisque le paquet n'existe pas dans
stretch.
Avatar
Seb
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
---1155178722-1776380740-1507195388=:17980
Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1; FORMAT=flowed
Content-Transfer-Encoding: 8BIT
Content-ID:
Bonjour,
Une remarque en passant : je n'ai pas observé ce genre de chose en
amd64 (et sur aucune de mes machines, que ce soit en 4.11 ou 4.12).

J'utilise les noyaux 686. (Parce que l'antique 'gqview' est le
visualisateur d'images qui a ma préférence -- geekie ne sait pas bien
effacer des images si je laisse la touche Delete appuyée, ce qui m'arrive
souvent -- et qu'il n'est plus maintenu ni packagé: j'ai gardé un .deb
mais il ne s'installe pas sur un système en 64 bits.)
Je ne sais pas si tu as indiqué plus haut la taille de la mémoire
installée

8 Go. Et rien qui en consomme beaucoup, sauf ponctuellement (VirtualBox).
et le chipset (ou le contrôleur disque). C'est un point à ne pas
négliger d'autant que je vois pae dans le nom du noyau.

Je ne sais pas comment trouver le nom du chipset; peux-tu m'indiquer
quelle serait la bonne commande ?
Avec un init systemV, c'est assez trivial. Avec la grouille
systemd/udev, c'est assez casse-gueule.

J'aurais préféré rester en systemV, mais l'option n'est pas proposée lors
de l'installation de Debian et je ne sais pas dans quelle mesure on peut
espérer que Devuan et Debian resteront synchrones.
La seule fois où j'ai dû faire ça, cela s'est soldé par un échec.

Aïe...
Seb.
---1155178722-1776380740-1507195388=:17980--
Avatar
Pascal Hambourg
Le 05/10/2017 à 11:12, BERTRAND Joël a écrit :
Seb a écrit :
Y a-t-il une méthode standard Debian qui me permettrait d'installer sans
trop souffrir le noyau 3.16 sur la Debian 9 ? (Un pointeur vers la bonne
page web m'irait amplement.)

    Avec un init systemV, c'est assez trivial. Avec la grouille
systemd/udev, c'est assez casse-gueule. La seule fois où j'ai dû faire
ça, cela s'est soldé par un échec.

Je l'avais fait quand Debian 9 stretch était encore en testing, peu
avant sa publication en stable. Pas de problème particulier, sauf avec
le GPU Radeon : en l'absence du firmware pourtant optionnel avec ce
modèle de GPU, l'initialisation du module radeon semblait ne pas aller à
son terme (il manquait des messages dans les logs du noyau) et
l'affichage se coupait. Pourtant le même noyau 3.16 initialisait
correctement le GPU même sans firmware avec le userland de Debian 8
jessie. Le dernier message du module radeon dans les logs du noyau
parlant de "user helper", il se peut fort bien que ce soit effectivement
une incompatibilité avec la version de systemd/udev de stretch. Aucun
problème en revanche si le firmware était présent, ni avec le noyau 4.9
de stretch avec ou sans firmware.
Avatar
BERTRAND Jo=c3=abl
Seb a écrit :
Bonjour,
Une remarque en passant : je n'ai pas observé ce genre de chose en
amd64 (et sur aucune de mes machines, que ce soit en 4.11 ou 4.12).

J'utilise les noyaux 686. (Parce que l'antique 'gqview' est le
visualisateur d'images qui a ma préférence -- geekie ne sait pas bien
effacer des images si je laisse la touche Delete appuyée, ce qui
m'arrive souvent -- et qu'il n'est plus maintenu ni packagé: j'ai gardé
un .deb mais il ne s'installe pas sur un système en 64 bits.)

Et en recompilant depuis les sources quitte à recompiler en 32 bits sur
un système 64 bits ?
Je ne sais pas si tu as indiqué plus haut la taille de la mémoire
installée

8 Go. Et rien qui en consomme beaucoup, sauf ponctuellement (VirtualBox).

Ça, ça peut être une piste. Peux-tu essayer avec moins de 4Go de
mémoire ? Le PAE est une ignoble bidouille qui permet au noyau d'adressé
plus de 4Go de mémoire (périphériques compris) au prix d'une complexité
accrue.
et le chipset (ou le contrôleur disque). C'est un point à ne pas
négliger d'autant que je vois pae dans le nom du noyau.

Je ne sais pas comment trouver le nom du chipset; peux-tu m'indiquer
quelle serait la bonne commande ?

lspci par exemple.
Avec un init systemV, c'est assez trivial. Avec la grouille
systemd/udev, c'est assez casse-gueule.

J'aurais préféré rester en systemV, mais l'option n'est pas proposée
lors de l'installation de Debian et je ne sais pas dans quelle mesure on
peut espérer que Devuan et Debian resteront synchrones.
La seule fois où j'ai dû faire ça, cela s'est soldé par un échec.

Aïe...

Bien cordialement,
JKB
Avatar
Pascal Hambourg
Le 05/10/2017 à 12:51, BERTRAND Joël a écrit :
    Une remarque en passant : je n'ai pas observé ce genre de chose en
amd64 (et sur aucune de mes machines, que ce soit en 4.11 ou 4.12).

J'utilise les noyaux 686. (Parce que l'antique 'gqview' est le
visualisateur d'images qui a ma préférence -- geekie ne sait pas bien
effacer des images si je laisse la touche Delete appuyée, ce qui
m'arrive souvent -- et qu'il n'est plus maintenu ni packagé: j'ai gardé
un .deb mais il ne s'installe pas sur un système en 64 bits.)

    Et en recompilant depuis les sources quitte à recompiler en 32 bits
sur un système 64 bits ?

Ou en activant le multi-arch et en installant les bibliothèques 32 bits
nécessaires ?
    Je ne sais pas si tu as indiqué plus haut la taille de la mémoire
installée

8 Go. Et rien qui en consomme beaucoup, sauf ponctuellement (VirtualBox).

    Ça, ça peut être une piste. Peux-tu essayer avec moins de 4Go de
mémoire ? Le PAE est une ignoble bidouille qui permet au noyau d'adressé
plus de 4Go de mémoire (périphériques compris) au prix d'une complexité
accrue.

Avoir (ou déclarer avec l'option mem=) moins de 4 Go de RAM ne
désactivera pas PAE. C'est une option en dur dans le noyau. Pour
désactiver PAE, je crois qu'il faut un noyau non PAE (ce qui fait perdre
des fonctionnalités comme le NX/XD bit).
Par ailleurs, il faut savoir que l'architecture amd64 met en oeuvre un
mécanisme d'adressage à plusieurs niveaux dérivé de PAE.
Avatar
BERTRAND Jo=c3=abl
Pascal Hambourg a écrit :
Le 05/10/2017 à 12:51, BERTRAND Joël a écrit :
Une remarque en passant : je n'ai pas observé ce genre de chose en
amd64 (et sur aucune de mes machines, que ce soit en 4.11 ou 4.12).

J'utilise les noyaux 686. (Parce que l'antique 'gqview' est le
visualisateur d'images qui a ma préférence -- geekie ne sait pas bien
effacer des images si je laisse la touche Delete appuyée, ce qui
m'arrive souvent -- et qu'il n'est plus maintenu ni packagé: j'ai gardé
un .deb mais il ne s'installe pas sur un système en 64 bits.)

Et en recompilant depuis les sources quitte à recompiler en 32
bits sur un système 64 bits ?

Ou en activant le multi-arch et en installant les bibliothèques 32 bits
nécessaires ?

Ça coule de source. Mais à force, ledit paquet risque de demander des
bibliothèques qui ne seront plus sur les versions récentes de debian...
Je ne sais pas si tu as indiqué plus haut la taille de la mémoire
installée

8 Go. Et rien qui en consomme beaucoup, sauf ponctuellement
(VirtualBox).

Ça, ça peut être une piste. Peux-tu essayer avec moins de 4Go de
mémoire ? Le PAE est une ignoble bidouille qui permet au noyau
d'adressé plus de 4Go de mémoire (périphériques compris) au prix d'une
complexité accrue.

Avoir (ou déclarer avec l'option mem=) moins de 4 Go de RAM ne
désactivera pas PAE. C'est une option en dur dans le noyau. Pour
désactiver PAE, je crois qu'il faut un noyau non PAE (ce qui fait perdre
des fonctionnalités comme le NX/XD bit).

Je pense (mais je n'ai pas regardé, il y a longtemps que je ne
bidouille plus le noyau Linux) qu'avec moins de 4 Go de mémoire, même
avec PAE, le système ne va pas essayer de mapper la mémoire sur plus de
32 bits d'adresses, donc n'essayera pas d'étendre l'adressage au-delà.
Par ailleurs, il faut savoir que l'architecture amd64 met en oeuvre un
mécanisme d'adressage à plusieurs niveaux dérivé de PAE.

Ça ne dépend pas des options de compilation et des scripts d'édition
des liens ? Il me semble qu'il est possible de forcer la taille des
pointeurs dans ces scripts. Si tu force un adressage 64 bits réels, je
ne vois pas ce qu'un mécanisme dérivé de PAE pourra bien venir faire
là-dedans.
Cordialement,
JKB
1 2 3 4 5