Hello,
Ca me rappelle il y a plusieurs années quand j'avais trouvé une petite
carte PCI pour faire du RAID (sata+IDE) à 2 balles, qui c'était révélée
être du "fakeraid"... Possibilité d'installer et d'utiliser le Raid0 qui
était dessus, mais il finissait par perdre les perfs jusqu'à l'octet/s :s
Souvent la machine freezait de longs moments !
Par contre c'était cool avec Windows. Ca sentait le "pilote" intégré à
Debian, selon mon avis par déduction absolument pas expert en la matière ;)
Peut-être suis-je complètement à coté de la plaque !!!
Après j'avoue que ca m'a toujours un peu perdu ces histoires de fakeraid...
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 ?
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>
>>>>
>>
Attachment:
signature.asc
Description: OpenPGP digital signature