Re: Performance RAID instable

[Seb <seb@h-k.fr>]

Hello,


> Après j'avoue que ca m'a toujours un peu perdu ces histoires de 
> fakeraid...

J'aurais dû préciser quelque chose qui n'était qu'implicite dans mon 
message initial: tout mes tableaux RAID sont en soft, gérés par 'mdadm'. 
Je n'utilise aucune carte RAID.

> J'ai souvenir que pour installer Debian sur du raid, il fallait 
> absolument ajouter dmraid=true dans la ligne de commande du cd 
> d'install, ce qui signifie qu'il s'agit de fakeraid et que c'est donc 
> géré par l'OS ?

Je configure le RAID soft avec le partitionneur de Debian (version 
manuelle), lors de l'installation.


Seb.


> Le 22/09/2017 à 17:09, Seb a écrit :
> > Bonjour,
> >
> >
> > > Les astuces que j'ai décrites permettent de maintenir les
> > > performances quand on écrit une grande quantité de données d'un coup
> > > ou bien une grandes quantité d'écritures aléatoirement réparties.
> > > C'est donné au cas où l'hypothèse que j'ai émise est la bonne, car ça
> > > colle très bien à ce que j'observe sur les supports amovibles. Reste
> > > à vérifier si l'architecture dont j'ai parlé est la même sur les SSD.
> > > J'irai jeter un oeil par curiosité.
> >
> > La comparaison me paraît limitée: sur mon système, je peux copier des
> > centaines de Mo sans aucun problème à pleine vitesse puis, une heure
> > plus tard, alors qu'il ne se passe rien de particulier sur la machine,
> > observer que mes disques SSD sont tout à coup devenus plus lents que
> > ma connexion
> > ADSL.
> >
> > > Je serais tenté de tester les disques avec l'outil de diagnostic
> > > constructeur, spécifique aux SSD, si il existe (je suis resté sur les
> > > magnétiques pour le stockage de masse (je veux dire autre que l'OS)).
> >
> > Je serais fort surpris que le problème soit lié aux disques:
> >
> > * un reboot résout le problème pour plusieurs heures;
> >
> > * ces disques fonctionnaient parfaitement juste avant le passage en
> > Debian 9, et incorrectement juste après;
> >
> > * j'observe la chose sur deux machines, dont une neuve.
> >
> > > D'ailleurs avec LVM ou RAID + hotswap ça peut se faire à chaud sans
> > > période d'arrêt ou très courte.
> >
> > Sous réserve d'avoir des disques SSD d'avance, ce qui n'est pas mon
> > cas...
> >
> >
> > Seb.
> >
> >
> > > Le vendredi 22 septembre 2017 à 16:12 +0200, Seb a écrit :
> > > > Hello,
> > > >
> > > >
> > > > > Les SSD prennent ils en charge TRIM ?
> > > >
> > > > Oui.
> > > >
> > > > ~>sudo smartctl -i /dev/sda | grep ^"Device Model"
> > > > Device Model:     Samsung SSD 850 EVO 1TB
> > > >
> > > > ~>sudo smartctl -i /dev/sdb | grep ^"Device Model"
> > > > Device Model:     Samsung SSD 850 EVO 1TB
> > > >
> > > > http://www.samsung.com/fr/consumer/memory-storage/ssd/850-evo/MZ-75E1
> > > > T0B/EU/
> > > > (^F TRIM)
> > > >
> > > > (Je m'étais assuré de ce point quand j'avais acheté les disques.)
> > > >
> > > > Je rappelle en outre que le même tableau RAID1 avec les mêmes disques
> > > > SSD
> > > > a fonctionné pendant longtemps sans aucun souci -- jusqu'au passage
> > > > de
> > > > cette machine de Debian 8 à Debian 9.
> > > >
> > > > > 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) ?
> > > >
> > > > Il m'arrive couramment de déplacer ou copier des centaines de Mo en
> > > > peu de
> > > > temps, mais ces moments ne coïncident pas avec la perte de
> > > > performance.
> > > > Des crontabs font des tas de jobs pour moi en sous-main, mais elles
> > > > les
> > > > faisaient aussi sous Debian 8.
> > > >
> > > > > Je n'utilise pas JFS, mais a t il été optimisé si possible pour
> > > > > respecter les contraintes techniques de ce genre de support ?
> > > >
> > > > J'ai utilisé JFS sur des tas de machines depuis 10-15 ans, des
> > > > disques
> > > > seuls, des tableaux RAID1, 5 et 6, je n'ai jamais eu de problème
> > > > comparable à celui que je constate aujourd'hui. J'ai signalé JFS pour
> > > > le
> > > > cas où quelqu'un aurait connaissance d'un changement dans la prise
> > > > en
> > > > charge de ce filesystem dans Debian, mais autrement, en lui-même, il
> > > > m'a
> > > > toujours semblé très solide.
> > > >
> > > > > 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.
> > > >
> > > > Merci pour ces astuces d'optimisation. Mon problème est toutefois
> > > > inverse:
> > > > empêcher la chute soudaine et inexpliquée des performances, plutôt
> > > > que
> > > > tirer autant de débit que possible d'un système fonctionnant
> > > > correctement
> > > > à la base :-)
> > > >
> > > >
> > > > Seb.
> > > >
> > > >
> > > > > > 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.smartmon
> > > > too
> > > > > > 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.smartmon
> > > > too
> > > > > > 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>