Re : Performance RAID instable
Bonjour
Quelques questions:
Les SSD prennent ils en charge TRIM ?
L'effondrement de performance ne serait-il consécutif à une écriture en
peu de temps de quelques centaines de Mo, ou bien de nombreuses
écritures très petites (< 32Ko environ) ?
Je n'utilise pas JFS, mais a t il été optimisé si possible pour
respecter les contraintes techniques de ce genre de support ?
Il faut que je vérifie si ce qui suit s'applique aux SSD. En tout cas
sur une clé USB bas de gamme ça fait des miracles.
Les stockages "solide" ou "flash" connaissent la notion de bloc
d'effacement. C'est à dire que quand on écrit une donnée on va modifier
sur un de ces blocs, si la donnée écrite diffère d'un seul bit du
contenu préalablement enregistré, il faut effacer tout le bloc et le
réécrire entièrement. Une exception, si les tous bits devant être
modifiés passent de l'état 0 à l'état 1 et pas l'inverse.
Donc pour un seul bit, on peut se retrouver à écrire en réalité un bloc
de l'ordre du Mo. Du gâchis en somme.
J'ai eu à utiliser une clé USB ces dernières semaines pour transférer
quelques Go d'un PC à un autre. En optimisant le système de fichiers
ext4 (la clé étatn une bouse de supermarché) j'ai ou atteindre un débit
entre 15 et 20 Mo/s. Au delà de mes espérances pour le support que
j'avais.
L'astuce consiste à configurer le système de fichier pour écrire par
blocs de taille multiple du bloc d'effacement.
Pour trouver la taille de ce bloc d'effacement, trouvez dans les
dépôts Debian le paquet flashbench. Le site donne des infos sur
l'interprétation des résultats: https://github.com/bradfa/flashbench
En cherchant une source pour expliquer l'optimisation d'un support
flash (usb ou SD) je retrouve sur la source qui m'a tout appris. Je la
redonne donc ici : https://blogofterje.wordpress.com/2012/01/14/optimiz
ing-fs-on-sd-card/
Elle explique aussi l'alignement des partitions, et le "segment size"
dont j'ai oublié de parler.
Dans le cas d'un RAID, il faudra faire des configurations similaires au
niveau de la grappe. C'est paramétrable et à l'époque des disques
magnétiques on optimisait déjà les performances en configurant finement
ses grappes. Un vieil exemple : http://monblog.system-linux.net/blog/20
11/07/02/modification-de-lalignement-disque-lors-de-linstallation-dune-
mandriva-2009-0/
Encore une fois, il faut vérifier si ça s'applique aux SSD, je pense
que oui, mais sans avoir de preuve pour l'instant. Je n'ai pas eu de
problème particulier en me contentant d'aligner mes partitions (il
supporte TRIM).
Le vendredi 22 septembre 2017 à 12:22 +0200, Seb a écrit :
> 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.smartmontoo
> ls.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.smartmontoo
> ls.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>
Reply to: