Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
1825 connectés 

  FORUM HardWare.fr
  Linux et OS Alternatifs
  Logiciels

  [FIXED] MDADM : Problème de performance en raid 1 & 5 soft

 


 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

[FIXED] MDADM : Problème de performance en raid 1 & 5 soft

n°1350722
bosstime
H1N1 ready
Posté le 10-01-2014 à 20:41:12  profilanswer
 

Hello world,
 
Je rencontre un soucis de performance avec 2 nouveaux raids logiciel avec mdadm qui remplacent mon ancien raid6 (au passage, le 6 c'est pas franchement utile :o)
 
Pour info, l'ancien raid avait était créé sous debian 5 en tant que raid5 il y a 3 ans avec 3 disques de 1To WD Green EADS puis a migré vers un raid 6 avec 5 disques à la suite des remplacement progressifs des disques et du besoin de place :D. Il avait alors des performances normales (230Mo/s soit quasiment 3 fois la vitesse du disque le plus lent - 80Mo/s pour le dernier Green EADS vivant :D - pour un raid de 5 disques dont 2 de parités) malgré des disques hétérogènes (des 2"5, des 3"5, des 4k, etc..).
 
Aujourd'hui, je suis donc parti sur un raid1 avec 2 disques identiques (des 3"5 Green EZRX) et un raid 5 avec les 3 autres, tous en 2"5 (Un WD Blue, un WD Red et un Samsung M8)
 
Pour le raid1, je suis à 140Mo/s, comme les 2 disques alors que normalement il devrait être doublé en lecture si je me trompe pas
Pour le raid5, je suis a 100Mo/s, le débit du disque le plus bas des 3, alors qu'il devrait être proche des 200Mo/s (nb_disque-1 * vitesse disque le plus lent)
 
Les partitions sont bien entendues alignées correctement et le système de fichier est en ext4 comme avant, tandis que la distro est la dernière debian et le raid a été créé sous cette dernière. J'ai l'impression que c'est un souci logiciel ou de conf mais j'arrive pas à trouver une solution.
 
Ce n'est pas forcément génant dans l'absolu ( wifi-limited :o ) mais j'avoue que ca me saoule quand même un peu... :D
 
Quelqu'un a déjà eu le soucis ?
 
update: Solution trouvée : augmenter le read ahead
 

Code :
  1. # recuperer la valeur actuelle
  2. blockdev --getra /dev/mdx
  3. # augmenter progressivement la valeur en doublant
  4. blockdev --setra 8192 /dev/mdx


 
 
Merci d'avance :)


Message édité par bosstime le 13-01-2014 à 13:42:15
mood
Publicité
Posté le 10-01-2014 à 20:41:12  profilanswer
 

n°1350739
goblin_rie​ur
ingé systemes unix
Posté le 11-01-2014 à 16:35:47  profilanswer
 

raid1 ne double pas la vitesse, c'est le 0+1 qui double la vitesse mais là il faut donc 4 disques....
 
Ceci dit 140Mo/s réel pour un raid1 soft c'est quand meme pas forcément un bon taux.... j'aurai plus vu du 180Mo/s avec des pics de perfs autour de 200 ...
 
pour le raid5 c'est pareil effectivement tu devrais avoir un taux proche du 200Mo/s voir un peu plus en moyenne avec des pics vers 250Mo/s
 
---------------------
 
peut être qu'en jouant avec les buffers d'I/O dans la conf des raids....
 
un raid materiel étant tellement plus fiable et surtout rapide, ...ça me donne une idée d'ailleur, peut être de mettre les disques dans un autre ordre pour que le plus lent ne soit pas le premier detecté pour que ça size les buffers softs au premier detecté peut être....  
 
là faut tester...
mais déjà avoir fait ça avec des disques hétérogène, faut pas oublié que c'est pas sencé marcher, ça ne marche que parce que le principe reste le meme....
 
je pense que c'est coté des buffers ou de l'ordre hardware des disques sur les bus et equilibrer ça avec l'ordre de detection à la création de la grappe que tu peux le plus jouer pour optimiser....


---------------
Collectionner les vieux serveurs c'est chouette mais c'est lourd et ça prend de la place ;)
n°1350750
bosstime
H1N1 ready
Posté le 12-01-2014 à 11:03:02  profilanswer
 

:hello: goblin

goblin_rieur a écrit :

raid1 ne double pas la vitesse, c'est le 0+1 qui double la vitesse mais là il faut donc 4 disques....
Ceci dit 140Mo/s réel pour un raid1 soft c'est quand meme pas forcément un bon taux.... j'aurai plus vu du 180Mo/s avec des pics de perfs autour de 200


Ah, je pensais qu'il profitait que les données étaient écrites en double pour paralléliser les lectures. Dans ce cas, c'est normal puisque ça correspond à la vitesse de mes disques
 

goblin_rieur a écrit :

peut être qu'en jouant avec les buffers d'I/O dans la conf des raids....


Je viens de regarder le read ahead (blockdev --getra) qui était à 4k et effectivement en l'augmentant à 8k j'arrive à 180Mo/s (ça baisse au delà de 8k). Bizarre qu'il soit configuré avec une valeur si conservatrice par défaut, je me souvenais pas avoir dû à bidouiller ce paramètre lorsque j'avais créé le raid précédant. Merci du tuyau en tout cas :)
 

goblin_rieur a écrit :

un raid materiel étant tellement plus fiable et surtout rapide, ...ça me donne une idée d'ailleur, peut être de mettre les disques dans un autre ordre pour que le plus lent ne soit pas le premier detecté pour que ça size les buffers softs au premier detecté peut être....  
 
là faut tester...


D'accord avec toi pour le matériel, mais je voulais tester le soft pour une utilisation @home et ça me suffit largement. Pas envie de mettre 200€ dans une carte contrôleur correcte, car avec les cartes entrée de gamme sans cache, je pense que le soft est équivalent.
 
Pour le fiabilité en revanche je suis moins sûr car si ta carte contrôleur crame, le raid est perdu. De mémoire, il n'y a toujours pas de standard pour les metadata du raid, non ?
 

goblin_rieur a écrit :

mais déjà avoir fait ça avec des disques hétérogène, faut pas oublié que c'est pas sencé marcher, ça ne marche que parce que le principe reste le meme....
 
je pense que c'est coté des buffers ou de l'ordre hardware des disques sur les bus et equilibrer ça avec l'ordre de detection à la création de la grappe que tu peux le plus jouer pour optimiser....


Là, il y a 2 écoles : disques identiques pour de meilleures perfs en théorie et disques différents pour éviter les problèmes de fiabilité. J'ai perdu 2 de mes greens EADS dans mon raid5 à 2 semaines d'intervalle. S'ils étaient tombé en même temps, je perdais tout (j'avais pas de spare à l'époque) :D
 
Merci pour ton aide en tout cas ;)

n°1350753
networkinf​o
Posté le 12-01-2014 à 11:34:02  profilanswer
 

D'où l'intérêt du raid6
Personnellement j'ai préféré mdadm au raid carte proprio

n°1350757
bosstime
H1N1 ready
Posté le 12-01-2014 à 11:43:40  profilanswer
 

networkinfo a écrit :

D'où l'intérêt du raid6
Personnellement j'ai préféré mdadm au raid carte proprio


 
Oui justement c'est pour ça que j'avais migré de raid5 à raid6 en chemin. Pratique avec mdadm, mais 2 jours pour reconstruire par contre... :/
 
Pour un truc maison, je reste avec un raid5 et un backup hebdomadaire des trucs vitaux en plus sur un disque externe :)

n°1350785
tybobab
Posté le 13-01-2014 à 12:18:10  profilanswer
 

Salut,
 
essaye : echo 32768 > /sys/block/mdxx/md/stripe_cache_size
 
Il te faut 512 Mo de ram libre et remplacer xx par le numéro de ton volume raid
 
Par exemple, avec 4*1To de WD Green j'obtenais 140mo/s et après réglage de ce paramètre, je suis pas loin des 400mo/s.

n°1350787
bosstime
H1N1 ready
Posté le 13-01-2014 à 13:38:40  profilanswer
 

tybobab a écrit :

Salut,
 
essaye : echo 32768 > /sys/block/mdxx/md/stripe_cache_size
 
Il te faut 512 Mo de ram libre et remplacer xx par le numéro de ton volume raid
 
Par exemple, avec 4*1To de WD Green j'obtenais 140mo/s et après réglage de ce paramètre, je suis pas loin des 400mo/s.


 :hello: ,
 
Le stripe_cache_size n'est utile que pour l'écriture, pas pour la lecture de mémoire. C'est d'ailleurs le 1er paramètre que je modifie (par contre je reste à 16384, je n'ai pas de gain au dessus) :D
 
J'ai retrouvé des perfs acceptables en augmentant le read ahead à 8k au lieu de 4k (pareil, au dessus de 8k, aucun gain voire une baisse)

n°1350800
goblin_rie​ur
ingé systemes unix
Posté le 13-01-2014 à 17:13:19  profilanswer
 

bien vue !


---------------
Collectionner les vieux serveurs c'est chouette mais c'est lourd et ça prend de la place ;)
n°1350802
gizmo15
Posté le 13-01-2014 à 17:27:46  profilanswer
 
n°1350807
bosstime
H1N1 ready
Posté le 13-01-2014 à 20:01:04  profilanswer
 


C'est toi qui m'a orienté sur la bonne piste ;)
 


Le sujet est clos :D J'ai mis la commande en première page pour que ça serve ;)

mood
Publicité
Posté le 13-01-2014 à 20:01:04  profilanswer
 

n°1350820
memaster
ki a volé mon 62?
Posté le 14-01-2014 à 09:05:34  profilanswer
 

j'ai le même genre de souci mais en écriture sur un raid0 de flashcard (branchés en master/master). j'avais fini par laisser tomber d'autres essais pour augmenter les perf.
on ne perds pas de data avec vos commandes?


Message édité par memaster le 14-01-2014 à 09:09:05

---------------
ma conduite intérieure .:R | memaster pilote officiel de la HFR Badoit-Auchan F1 Team | zéro tracas, zéro blabla MMa.ster
n°1350825
bosstime
H1N1 ready
Posté le 14-01-2014 à 09:53:29  profilanswer
 

A priori non, sauf si tu as une coupure de courant ou un reboot en pleine écriture. Tu en perdras d'autant plus que ton stripe_cache_size est gros j'imagine.
 
Mais j'espère que tu ne mets pas des trucs vitaux sur ton combo raid0/ flashcard, à moins d'être très joueur :D

n°1350856
gizmo15
Posté le 14-01-2014 à 16:13:14  profilanswer
 

je drap pour pas perdre le topic ;)

n°1350872
memaster
ki a volé mon 62?
Posté le 14-01-2014 à 20:16:36  profilanswer
 

bosstime a écrit :

A priori non, sauf si tu as une coupure de courant ou un reboot en pleine écriture. Tu en perdras d'autant plus que ton stripe_cache_size est gros j'imagine.
 
Mais j'espère que tu ne mets pas des trucs vitaux sur ton combo raid0/ flashcard, à moins d'être très joueur :D


je viens de re-regarder, en lecture j'ai 180Mo/s, donc cela me semble bien pour du PATA, mon read ahead est à 4096.
 
par contre en écriture je ne sais plus, mais de mémoire c'était assez faible et je trouvais cela assez bizarre.
edit : un test dd me donne 40Mo/s
 
edit2 : j'ai posé mon OS et mon /home dessus mais les données vitales sont synchro ailleurs donc pas perdues. ;)

Message cité 2 fois
Message édité par memaster le 14-01-2014 à 20:22:03
n°1350873
bosstime
H1N1 ready
Posté le 14-01-2014 à 20:58:36  profilanswer
 

memaster a écrit :


je viens de re-regarder, en lecture j'ai 180Mo/s, donc cela me semble bien pour du PATA, mon read ahead est à 4096.
 
par contre en écriture je ne sais plus, mais de mémoire c'était assez faible et je trouvais cela assez bizarre.
edit : un test dd me donne 40Mo/s
 
edit2 : j'ai posé mon OS et mon /home dessus mais les données vitales sont synchro ailleurs donc pas perdues. ;)


 
40Mo/s sur des flashcard ça ne me parait pas spécialement "lent" car les mémoires flash sur ce genre de périph' (hors ssd) ne sont pas forcément rapides en écriture. Il n'y a que les disques durs voire les ssd qui écrivent quasiment aussi vite qu'ils ne lisent en séquentiel :D
 
J'ai une clé (usb2, certes) qui lit à 30Mo/s mais qui atteint péniblement les 10Mo/s en écriture donc on est dans les mêmes proportions.  
 
Essaie de faire varier le stripe_cache_size, c'est un des params qui influe fortement sur l'écriture (hors alignement des partitions car je ne pense pas que les flashcard ont des secteurs de 4k ?)
 
Il faut aussi peut être checker si tes cartes sont bien détectées en "ssd" et non comme un disque classique, il paraît que ça améliore les perfs pour l'ordonnanceur des i/o, mais ça joue plutôt à mon sens sur des petites écritures aléatoires et non du séquentiel comme dd...
 
Vérifier que la commande (à faire pour les disques et les grappes raids) te renvoie bien 0 pour tout ce qui n'est pas détecté comme un disque à plateaux :

Code :
  1. cat /sys/block/sdxxx/queue/rotational


 
:)

n°1350887
memaster
ki a volé mon 62?
Posté le 15-01-2014 à 09:28:45  profilanswer
 

faudra que je vérifie @home les spécifs ecrites dessus. Mais normalement c'est 2x celle ci :
http://www.amazon.fr/gp/product/B0 [...] =computers
 
notée pour 70MB/s en ecriture et 90MB/s en lecture. j'avais fait d'autres recherche sur cette carte komputerbay et les résultats vu par d'autres concordaient.
 
pour en revenir à mon pb :
si en lecture le débit me semble respecté avec mes mesures 2x90=180,
en écriture, je n'obtiens pas 140 (cad 2x70). d'où mon :heink:  A l'usage je ressens la différence lorsque
j'installe du soft ou écriture de videos : assez rare. C'est une station bureautique [:_jbm]  
 
je vais donc voir pour augmenter le stripe_cache_size lorsque j'aurais un instant de calme
et je reviendrais ici exposer le résultat. :jap:


---------------
ma conduite intérieure .:R | memaster pilote officiel de la HFR Badoit-Auchan F1 Team | zéro tracas, zéro blabla MMa.ster
n°1350960
memaster
ki a volé mon 62?
Posté le 16-01-2014 à 09:47:23  profilanswer
 

bosstime a écrit :


 :hello: ,
 
Le stripe_cache_size n'est utile que pour l'écriture, pas pour la lecture de mémoire. C'est d'ailleurs le 1er paramètre que je modifie (par contre je reste à 16384, je n'ai pas de gain au dessus) :D
 
J'ai retrouvé des perfs acceptables en augmentant le read ahead à 8k au lieu de 4k (pareil, au dessus de 8k, aucun gain voire une baisse)


Code :
  1. # cat /sys/block/md0/md/stripe_cache_size
  2. cat: /sys/block/md0/md/stripe_cache_size: Aucun fichier ou dossier de ce type


une idée? [:kc]
 
edit : :non:  raid0


Message édité par memaster le 16-01-2014 à 10:28:47

---------------
ma conduite intérieure .:R | memaster pilote officiel de la HFR Badoit-Auchan F1 Team | zéro tracas, zéro blabla MMa.ster
n°1350970
memaster
ki a volé mon 62?
Posté le 16-01-2014 à 10:27:58  profilanswer
 

memaster a écrit :


je viens de re-regarder, en lecture j'ai 180Mo/s, donc cela me semble bien pour du PATA, mon read ahead est à 4096.
 
par contre en écriture je ne sais plus, mais de mémoire c'était assez faible et je trouvais cela assez bizarre.
edit : un test dd me donne 40Mo/s
 
edit2 : j'ai posé mon OS et mon /home dessus mais les données vitales sont synchro ailleurs donc pas perdues. ;)


aujourd'hui je suis entre 90MB/s et 140MB/s

Code :
  1. # dd if=/dev/zero of=/test.data bs=1M count=1024 conv=fdatasync
  2. 1024+0 enregistrements lus
  3. 1024+0 enregistrements écrits
  4. 1073741824 octets (1,1 GB) copiés, 7,7277 s, 139 MB/s
  5. root@ubuntu-desktop:/# dd if=/dev/zero of=/home/memaster2013/test.data bs=1M count=1024 conv=fdatasync
  6. 1024+0 enregistrements lus
  7. 1024+0 enregistrements écrits
  8. 1073741824 octets (1,1 GB) copiés, 11,4763 s, 93,6 MB/s


c'est qd même bizarre cette histoire [:psywalk]


---------------
ma conduite intérieure .:R | memaster pilote officiel de la HFR Badoit-Auchan F1 Team | zéro tracas, zéro blabla MMa.ster
n°1351110
bosstime
H1N1 ready
Posté le 17-01-2014 à 22:02:54  profilanswer
 

Bizarre en effet... Peut être avais tu testé avec un bs différent (plus petit) ?

n°1351185
memaster
ki a volé mon 62?
Posté le 20-01-2014 à 11:28:32  profilanswer
 

bosstime a écrit :

Bizarre en effet... Peut être avais tu testé avec un bs différent (plus petit) ?


non, je crois pas. j'ai toujours fait du copié-collé de cette commande pour les tests :sarcastic:  
 
déjà la grande différence d'écriture entre les 2 répertoire / et /home me semble :heink:  
c'est le même raid, juste 2 partoches disjointes (même formattage).


---------------
ma conduite intérieure .:R | memaster pilote officiel de la HFR Badoit-Auchan F1 Team | zéro tracas, zéro blabla MMa.ster

Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Linux et OS Alternatifs
  Logiciels

  [FIXED] MDADM : Problème de performance en raid 1 & 5 soft

 

Sujets relatifs
python comment afficher les emails d'un seul destinataireProblème de dépendance pour le paquet libapache2-mod-fastcgi
Problème FTPProblème avec Fail2ban
Problème clef wifiProblème cohabition ubuntu win8
Réutilisation DD : 2x2 To -> 4To pour un raid 5Kali linux, sauvegarder les modifications et problème de taille
[RESOLU] Problème avec UnetBootin sur CentOS 6.4Problème de boot avec Grub
Plus de sujets relatifs à : [FIXED] MDADM : Problème de performance en raid 1 & 5 soft


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR