Performances minables RAID5 logiciel DEBIAN Server

Performances minables RAID5 logiciel DEBIAN Server - Logiciels - Linux et OS Alternatifs

Marsh Posté le 29-04-2010 à 18:24:24    

Bonjour à toutes et à tous,
 
 
Je n'ai pas pour habitude de poster mes soucis... car généralement, je trouves des solutions sur les forums comme celui-ci !!! Mais la, je suis à court d'idées... je vais tenter de faire court,
 
Ma config :
- Core deux duo 5200 (2.5Ghz)
- 2 Go DDR2 6400
- Carte mère Gygabite GA-G31M-ES2L
- 1x 80Go (pour DEBIAN)
- 3x 1.5 To WD 5400Tr/min 64Mo cash
 
J'installe DEBIAN Je monte mon RAID 5 logiciel sans problème avec mdadm, je déplace sur mon RAID 2.6To de données a partir de windows 7 (bécanne en I7 GTX295 etc ca ne vien pas de là...) et d'un réseau GIGABIT doté de câble compatibles et supercopier m'annonce 24h !!! vitesse moyenne de copie : 25Mo/s la déception en image ICI
 
Avec la même configuration et Windows serveur 2008, un RAID 5 (seul différence : les disques formatés en NTFS) la vitesse de copie était de 80Mo/s en moyenne :-D
 
Vous vous demanderez pourquoi je ne suis pas resté tout simplement sous Windows ... et bien car ce dernière ne permet pas d'étendre un RAID 5 logiciel sans le casser et perdre les données, alors que GNU et Linux oui.
 
Que puis-je faire pour retrouver ces performance sous DEBIAN ?
 
Je tenterai bien de formater mon raid 5 en NTFS mais est-ce possible, comment faire, et est-ce que cela changera quelque chose ?
 
D'avance merci pour l'intérêt que vous porterez à mon appel a l'aide ...
 
Voici quelques info utiles tirées de DEBIAN :
 

Citation :

SERVEUR:/home/flust# hdparm -Tt /dev/sdb
/dev/sdb:
 Timing cached reads:   2492 MB in  2.00 seconds = 1245.70 MB/sec
 Timing buffered disk reads:  296 MB in  3.00 seconds =  98.63 MB/sec
 
 
SERVEUR:/home/flust# hdparm -Tt /dev/sdc
/dev/sdc:
 Timing cached reads:   2452 MB in  2.00 seconds = 1225.57 MB/sec
 Timing buffered disk reads:  300 MB in  3.01 seconds =  99.72 MB/sec
 
 
SERVEUR:/home/flust# hdparm -Tt /dev/sdd
/dev/sdd:
 Timing cached reads:   2476 MB in  2.00 seconds = 1237.51 MB/sec
 Timing buffered disk reads:  282 MB in  3.01 seconds =  93.60 MB/sec
 
RAID 5 :
SERVEUR:/home/flust# hdparm -Tt /dev/md0
/dev/md0:
 Timing cached reads:   2492 MB in  2.00 seconds = 1245.50 MB/sec
 Timing buffered disk reads:  472 MB in  3.01 seconds = 156.88 MB/sec
 
SERVEUR:/home/flust# hdparm -i /dev/sdb
 
/dev/sdb:
 
 Model=WDC WD15EARS-00Z5B1                     , FwRev=80.00A80, SerialNo=     WD-WMAVU2167815
 Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=50
 BuffType=unknown, BuffSize=0kB, MaxMultSect=16, MultSect=?16?
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=18446744072344861488
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio3 pio4  
 DMA modes:  mdma0 mdma1 mdma2  
 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6  
 AdvancedPM=no WriteCache=enabled
 Drive conforms to: Unspecified:  ATA/ATAPI-1,2,3,4,5,6,7
 
 * signifies the current active mode
 
SERVEUR:/home/flust# hdparm -i /dev/sdc
 
/dev/sdc:
 
 Model=WDC WD15EARS-00Z5B1                     , FwRev=80.00A80, SerialNo=     WD-WMAVU2630647
 Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=50
 BuffType=unknown, BuffSize=0kB, MaxMultSect=16, MultSect=?16?
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=18446744072344861488
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio3 pio4  
 DMA modes:  mdma0 mdma1 mdma2  
 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6  
 AdvancedPM=no WriteCache=enabled
 Drive conforms to: Unspecified:  ATA/ATAPI-1,2,3,4,5,6,7
 
 * signifies the current active mode
 
SERVEUR:/home/flust# hdparm -i /dev/sdd
 
/dev/sdd:
 
 Model=WDC WD15EARS-00Z5B1                     , FwRev=80.00A80, SerialNo=     WD-WMAVU1324156
 Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=50
 BuffType=unknown, BuffSize=0kB, MaxMultSect=16, MultSect=?16?
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=18446744072344861488
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio3 pio4  
 DMA modes:  mdma0 mdma1 mdma2  
 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6  
 AdvancedPM=no WriteCache=enabled
 Drive conforms to: Unspecified:  ATA/ATAPI-1,2,3,4,5,6,7
 
 


Message édité par mlevain le 29-04-2010 à 18:35:28
Reply

Marsh Posté le 29-04-2010 à 18:24:24   

Reply

Marsh Posté le 29-04-2010 à 19:22:50    

je commencerai par tester en local sur le serveur ...

Citation :

dd if=/dev/md0 of=/dev/null bs=4096 count=1000000


Ca va lire 4Go sur ta pile raid (ou moins si tu n'as pas tant de donner) et les envoyer à la poubelle (ça ne supprime rien de ta pile, c'est comme si ça copiait dans le vide si tu veux)
 
puis :

Citation :

dd if=/dev/zero of=/point/de/montage/de/ton/raid/test.bidon bs=4096 count=1000000


ça va écrire un fichier test.bidon de 4Go
 
avec dd tu verras les vitesses de lecture/écriture et le temps d'exécution
 
si déjà là c'est pourri => optimisation du FS
 
sinon => optimisation de Samba

Reply

Marsh Posté le 29-04-2010 à 19:24:56    

Les paramètres par défaut du raid5 sous Linux favorisent très nettement la sécurité des données, au détriment des performances.
 
Pour améliorer les performances en écriture raid5, il faut augmenter la valeur de "stripe cache"
Ce réglage est situé dans le pseudo fichier "stripe_cache_size".
Tu peux afficher la valeur courante:

# cat /sys/block/md0/md/stripe_cache_size

(généralement elle est très basse par défaut)
 
Tu peux changer la valeur comme suit (ex: 8192)

# echo 8192 > /sys/block/md0/md/stripe_cache_size


A toi de tatonner pour trouver la valeur optimale (8192 semble pas mal si tu manques d'inspiration).
 
Pour les performances en lecture (hdparm -Tt), tu peux en théorie obtenir les performances de 2 disques, donc environ 200Mo/s dans ton cas.
Tu peux ajuster la valeur du "read ahead cache" avec la commande blockdev.
Afficher la valeur courante:

# blockdev --getra /dev/md0


Tu peux changer la valeur (il vaut mieux mettre une puissance de 2):

# blockdev --setra 16384 /dev/md0

Pareil qu'en écriture, à toi de tester la valeur qui donne les meilleures performances, 16384 étant un bon choix par défaut.
 
 
Pour améliorer très largement la performance de vérification/reconstruction du raid5 après un crash, tu peux ajouter une "bitmap" à ton raid (si tu l'as pas déja fait au moment de la création). Cela pénalise très peu les performances et fait gagner un temps fou en cas de crash de la machine:

# mdadm --grow -b /dev/md0

La bitmap permet de ne reconstruire que les données qui étaient en cours de modification sur le raid5, plutot que de reconstruire l'intégralité !
 
Avec ces 3 réglages, tes performances devraient décoller !
 
Concernant d'éventuelles optimisations du filesystem: inutile de te fatiguer, dans le cas du raid soft, Linux se débrouille tout seul pour effectuer les réglages optimaux lors du formattage, il n'y a donc rien à améliorer de ce coté.


Message édité par [Albator] le 29-04-2010 à 19:27:07
Reply

Marsh Posté le 29-04-2010 à 20:59:27    

merci Albator, ça va me servir aussi !!

Reply

Marsh Posté le 01-05-2010 à 19:34:41    

Bonjour à vous deux !
 
Dans un première temps je vous remercie pour vos réponses (quasi simultanées) :) et l'intérêt que vous avez portez à mon message. Je ne m'attendais pas à des réponses aussi construites et explicites.
 
Je vais répondre étape par étape,
 
Réponse à Fighting_falcon :
 

Citation :

SERVEUR:/home/flust# dd if=/dev/md0 of=/dev/null bs=4096 count=1000000
1000000+0 enregistrements lus
1000000+0 enregistrements écrits
4096000000 bytes (4,1 GB) copied, 21,5787 s, 190 MB/s
 
SERVEUR:/home/flust# dd if=/dev/zero of=/mnt/raid/test.bidon bs=4096 count=1000000
1000000+0 enregistrements lus
1000000+0 enregistrements écrits
4096000000 bytes (4,1 GB) copied, 181,842 s, 22,5 MB/s


 
On remarque que la vitesse de mon RAID et médiocre, j'ai donc de suite suivit les conseils de [Albator] :
 
Réponse a Albator :
 

Citation :

SERVEUR:/home/flust# cat /sys/block/md0/md/stripe_cache_size
256
SERVEUR:/home/flust# echo 8192 > /sys/block/md0/md/stripe_cache_size
 
SERVEUR:/home/flust# blockdev --getra /dev/md0
512
SERVEUR:/home/flust# blockdev --setra 16384 /dev/md0
 
SERVEUR:/home/flust# mdadm --grow -b /dev/md0
mdadm: an md device must be given in this mode


 
 
Après modifs de Albator :
 

Citation :

SERVEUR:/home/flust# dd if=/dev/zero of=/mnt/raid/test.bidon bs=4096 count=1000000
1000000+0 enregistrements lus
1000000+0 enregistrements écrits
4096000000 bytes (4,1 GB) copied, 164,041 s, 25,0 MB/s


 
On remarque une légère amélioration, mais lorsque j'ai réaliser un transfert de fichier avec les paramètres de mémoire cache à 8192 en écriture et 16384 en lecture supercopier m'affichait environ 10Mo/s supplémentaire lors d'un transfert de Windows a Linux sur mon raid 5, c'est une petite victoire mais qui fait plaisir, car l'amélioration de la vitesse de transfert est belle est bien réalisable !!!
 
J'ai également remarqué, Albator, que les paramètres de cache que je modifiais se réinitialisent lors du redémarrage du serveur, peux-tu me donner l'astuce pour les ajouter par défaut ?
 
J'ai posté mon problème sur d'autre forum, une personne ma intrigué en me parlant de la taille des bloc systeme (voir massage ci-dessous) auriez vous des conseils à me donner de ce coté ?
 

Citation :

Les perf raid5 avec mdadm dépendandent beaucoup de la taille par défaut des blocs du système de fichier et du réglage du chunk-size sur ton array.
Jette un oeil à la fin de cet article : http://tldp.org/HOWTO/Software-RAID-HOWTO-5.html


 
Merci encore !
 


---------------
i7 4770k-4.4 GHz  , GTX 780, 8GO 2400 DDR3, Souris FNATIC, Clavier KBT Pure Pro...
Reply

Marsh Posté le 01-05-2010 à 19:54:44    

Le réglage que je t'ai filé n'a pour ainsi dire rien changé: ton problème est ailleurs. Ton raid, tu l'as crée avec quels paramètres ?
 
Donne voir le résultat de

# cat /proc/mdstat

J'espère que t'as pas eu la mauvaise idée de réduire la taille des chunk (comme on peut le lire sur des mauvais forums/tutoriaux), la valeur de 64 Ko étant vraiment le minimum à utiliser. Car ça expliquerait des performances médiocres en écriture.
 
Pour la 3ème commande que je t'ai filé, la bitmap, je me suis trompé dans la syntaxe, la vraie commande est:

# mdadm -G /dev/md0 -b internal

Mais ça n'impacte pas vraiment les performances.
 
Pour que tes réglages soient appliqués au redémarrage, à toi d'ajouter les commandes dans un script de démarrage (variable selon ta distribution).
 
Quand aux mecs qui t'embrouillent avec des histoires de bloc système sans plus de précision, ne te laisse pas avoir: sur la plupart des forums et des tutoriaux qu'on trouve sur le net, dès qu'on aborde le sujet du tuning de performances en raid, on se fait barratiner genre "les performances en raid5 dépendent de facteurs aussi nombreux que complexes". En gros le mec n'y connait rien et donne des pistes au hasard.
 
Si tu as la possibilité de refaire ton raid, je te suggère de faire un essai en raid-0 pour voir si tu obtiens un meilleur résultat (histoire de voir si ton pb vient du raid5 seulement, ou du raid tout court).
 
Exemple chez moi avec 3 disques de 1 To en raid0:  

$ dd if=/dev/zero of=/mnt/storage/raid/test.bidon bs=4096 count=1000000  
1000000+0 enregistrements lus
1000000+0 enregistrements écrits
4096000000 octets (4,1 GB) copiés, 18,1461 s, 226 MB/s

Ca te donne un ordre de grandeur de ce que tu devrais avoir chez toi.

Reply

Marsh Posté le 01-05-2010 à 20:05:58    

Tu vas être surpris l'ami !
 

Citation :

SERVEUR:/home/flust# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]  
md0 : active raid5 sdb1[0] sdd1[2] sdc1[1]
      2930271872 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]


 
Le chuck est bien à "64K" mais ce n'est rien, mon raid peut-être modifier ou supprimer, il ne contient aucune donnée importante ou non sauvegardées.
- Puis-je changer cette valeur ?
- Sans détruire le raid ?
- Sans formater les données ?
 
Pour info j'ai créer mon RAID avec ce tuto :
 
http://www.actualinux.net/2009/12/ [...] us-debian/


---------------
i7 4770k-4.4 GHz  , GTX 780, 8GO 2400 DDR3, Souris FNATIC, Clavier KBT Pure Pro...
Reply

Marsh Posté le 01-05-2010 à 20:18:52    

mlevain a écrit :

Puis-je changer cette valeur ?


oui (paramètre sur la ligne de commande mdadm)

 
mlevain a écrit :

Sans détruire le raid ?


J'ai peur que non, si je ne dis pas de connerie, il faut recréer ton raid, ce qui revient à détruire l'ancien

 
mlevain a écrit :

Sans formater les données ?


bah si recréation du raid, du coup perte des données ...

  

edit : ah j'oubliais,

mlevain a écrit :

Dans un première temps je vous remercie pour vos réponses (quasi simultanées) :) et l'intérêt que vous avez portez à mon message. Je ne m'attendais pas à des réponses aussi construites et explicites.


Mais de rien, et merci pour ton merci ;)

 


edit 2 : autre chose, je viens de lire le tuto sur ton lien, tu as suivi sa procédure à la lettre ? parce que si oui, je te recommande (si tu en es à refaire ton raid) de faire des partitions "Linux raid autodetect" (type fd) au lieu des partoches "Linux" classiques (type 83) ...


Message édité par fighting_falcon le 01-05-2010 à 20:24:16
Reply

Marsh Posté le 01-05-2010 à 20:19:57    

OK, le tutorial est correct.
Non tu ne peux pas  changer le chunk size ou changer le niveau de raid sans tout péter ... Il faut stopper la grappe et la recréer à chaque fois.
 
Arrêter la grappe:

# mdadm -S /dev/md0


 
Tu peux essayer les 2 combinaisons suivantes pour voir:
 
- raid 0 avec chunk à 64K

# mdadm -C /dev/md0 --level=raid0 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1


- raid 5 avec chunk à 128K

# mdadm -C /dev/md0 --level=raid5 --chunk=128 -b internal --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1


Puis formatter et tester à nouveau le "dd" en écriture ...
Pour le raid5, il faut évidemment attendre que la synchro initiale soit terminée (évidemment sinon ça plombe les performances) et activer les réglages que je t'ai donnés précédemment (pas utiles en raid0 normalement),


Message édité par [Albator] le 01-05-2010 à 20:22:18
Reply

Marsh Posté le 01-05-2010 à 20:35:27    

Tu penses que je peux refaire mon raid avec la valeur Chunk à 128k et cela résoudrai mon problème ? Je lance la synchro :-) je commence à maitriser les ligne de commandes !
 

Citation :

SERVEUR:/home/flust# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]  
md0 : active (auto-read-only) raid5 sdd1[3](S) sdc1[1] sdb1[0]
      2930271744 blocks level 5, 128k chunk, algorithm 2 [3/2] [UU_]


 
 

Citation :

SERVEUR:/home/flust# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]  
md0 : active raid5 sdd1[3] sdc1[1] sdb1[0]
      2930271744 blocks level 5, 128k chunk, algorithm 2 [3/2] [UU_]
      [>....................]  recovery =  0.4% (6299164/1465135872) finish=256.3min speed=94847K/sec


 
 
Je donne des nouvelle dès demain,
 
Bonne soirée


Message édité par mlevain le 01-05-2010 à 20:48:32

---------------
i7 4770k-4.4 GHz  , GTX 780, 8GO 2400 DDR3, Souris FNATIC, Clavier KBT Pure Pro...
Reply

Marsh Posté le 01-05-2010 à 20:35:27   

Reply

Marsh Posté le 01-05-2010 à 20:49:44    

Rien que la vitesse de synchro 94847K/sec indique que tu parviens à écrire à une telle vitesse ... c'est déja pas mal :)

Reply

Marsh Posté le 02-05-2010 à 11:58:12    

[Albator] a écrit :

Rien que la vitesse de synchro 94847K/sec indique que tu parviens à écrire à une telle vitesse ... c'est déja pas mal :)


mouais, enfin généralement mdadm s'emballe au début d'une synchro et se calme ensuite ...
 
 
mlevain >
sinon, puisque tu as recréé ton raid, tu as modifié tes partitions sd[b-d]1 en type "0xfd" ou pas ?

Reply

Marsh Posté le 02-05-2010 à 13:08:24    

Salut !
 
Bon voila, on avance tout doucement mais on avance !
 
J'ai donc hier détruit mon RAID puis reconstruit avec un CHUNK à 128
 
voici les resultats :
 

Citation :

SERVEUR:/home/flust# dd if=/dev/zero of=/mnt/raid/test.bidon bs=4096 count=100000
100000+0 enregistrements lus
100000+0 enregistrements écrits
409600000 bytes (410 MB) copied, 13,2585 s, 30,9 MB/s
 
SERVEUR:/home/flust# echo 8192 > /sys/block/md0/md/stripe_cache_size
SERVEUR:/home/flust# blockdev --setra 16384 /dev/md0
 
SERVEUR:/home/flust# dd if=/dev/zero of=/mnt/raid/test.bidon bs=4096 count=100000
100000+0 enregistrements lus
100000+0 enregistrements écrits
409600000 bytes (410 MB) copied, 11,6188 s, 35,3 MB/s


 
Est-il possible de modifier le chunk et de l'augmenter et de combien ?
 
Merci


Message édité par mlevain le 02-05-2010 à 13:08:41
Reply

Marsh Posté le 02-05-2010 à 14:00:46    

Ca reste super lent au vu de la config ... (le chunk à 64 Ko ne devrait poser aucun pb à un core2duo ...)
Tu peux augmenter sa taille par puissance de 2 jusqu'à autant que tu veux à priori, mais au delà de 512 Ko ça devient vraiment gros (je suis déja monté à 2 Mo sur un PC avec un vieux CPU cela dit).
 
Essaye d'abord différentes valeurs de stripe_cache_size (petites commes 384, 512, 768, 1024... puis grosses comme 16384, 32768, ne va pas au delà) pour voir si ça améliore les perfs.
Regarde sur cet article:
http://peterkieser.com/2009/11/29/ [...] -transfer/
On voit qu'il y a un rapport ~4 en écriture entre le stripe cache à 256 et 8192 !
 
Sinon, essaye de reformatter en forçant les optimisations du filesystem (options -b et -E à rajouter sur ta commande de formattage), par exemple pour ton raid5 128Ko:

# mkfs.ext4 -b 4096 -E stride=32,stripe-width=64 /dev/md0


Message édité par [Albator] le 02-05-2010 à 14:09:45
Reply

Marsh Posté le 02-05-2010 à 15:32:26    

Effectivement c'est lent ... j'ai donc réaliser plusieurs tests que voici, la meilleur configue reste donc, comme l'indique ton lien, 8192 en écriture et 16384 en leccture, la lecture ne posant de toute facon pas de problème depuis le début :
 

Citation :

SERVEUR:/home/flust# echo 384 > /sys/block/md0/md/stripe_cache_size
SERVEUR:/home/flust# blockdev --setra 768 /dev/md0
SERVEUR:/home/flust# dd if=/dev/zero of=/mnt/raid/test.bidon bs=4096 count=100000
100000+0 enregistrements lus
100000+0 enregistrements écrits
409600000 bytes (410 MB) copied, 13,3585 s, 30,7 MB/s
 
 
SERVEUR:/home/flust# echo 512 > /sys/block/md0/md/stripe_cache_size
SERVEUR:/home/flust# blockdev --setra 1024 /dev/md0
SERVEUR:/home/flust# dd if=/dev/zero of=/mnt/raid/test.bidon bs=4096 count=100000
100000+0 enregistrements lus
100000+0 enregistrements écrits
409600000 bytes (410 MB) copied, 12,5879 s, 32,5 MB/s
 
 
SERVEUR:/home/flust# echo 1024 > /sys/block/md0/md/stripe_cache_size
SERVEUR:/home/flust# blockdev --setra 2048 /dev/md0
SERVEUR:/home/flust# dd if=/dev/zero of=/mnt/raid/test.bidon bs=4096 count=100000
100000+0 enregistrements lus
100000+0 enregistrements écrits
409600000 bytes (410 MB) copied, 12,5368 s, 32,7 MB/s
 
 
SERVEUR:/home/flust# echo 2048 > /sys/block/md0/md/stripe_cache_size
SERVEUR:/home/flust# blockdev --setra 4096 /dev/md0
SERVEUR:/home/flust# dd if=/dev/zero of=/mnt/raid/test.bidon bs=4096 count=100000
100000+0 enregistrements lus
100000+0 enregistrements écrits
409600000 bytes (410 MB) copied, 12,1088 s, 33,8 MB/s
 
SERVEUR:/home/flust# echo 8192 > /sys/block/md0/md/stripe_cache_size
SERVEUR:/home/flust# blockdev --setra 16384 /dev/md0
SERVEUR:/home/flust# dd if=/dev/zero of=/mnt/raid/test.bidon bs=4096 count=100000
100000+0 enregistrements lus
100000+0 enregistrements écrits
409600000 bytes (410 MB) copied, 11,2581 s, 36,4 MB/s
 
SERVEUR:/home/flust# echo 16384 > /sys/block/md0/md/stripe_cache_size
SERVEUR:/home/flust# blockdev --setra 32768 /dev/md0
SERVEUR:/home/flust# dd if=/dev/zero of=/mnt/raid/test.bidon bs=4096 count=100000
100000+0 enregistrements lus
100000+0 enregistrements écrits
409600000 bytes (410 MB) copied, 12,3305 s, 33,2 MB/s


 
Je tente donc un formatage comme proposé avec la commande  
 

Citation :

# mkfs.ext4 -b 4096 -E stride=32,stripe-width=64 /dev/md0


 
Le formatage ce fait déjà plus vite qu'avec les stripe_cache_size par défaut
 
Je te donne les résultats dans quelques instants ...
 
Merci encore pour ton aide précieuse et efficace !
 
Edit : Lorsqu'on aura résolu le problème, je posterai un tutoriel pour les gens rencontrons les mêmes soucis, et je sais qu'il y en a plus d'un !


Message édité par mlevain le 02-05-2010 à 15:34:11

---------------
i7 4770k-4.4 GHz  , GTX 780, 8GO 2400 DDR3, Souris FNATIC, Clavier KBT Pure Pro...
Reply

Marsh Posté le 02-05-2010 à 16:43:13    


 
Bon nous y arrivons, j'ai donc formater mon RAID en EXT4 avec la commande que tu m'as donné et voici les résultats du test :
 

Citation :

SERVEUR:/home/flust# dd if=/dev/zero of=/mnt/raid/test.bidon bs=4096 count=1000000
1000000+0 enregistrements lus
1000000+0 enregistrements écrits
4096000000 bytes (4,1 GB) copied, 96,5306 s, 42,4 MB/s


 
Encore des améliorations :-) mais pas de débridage complet du bousin :-S


---------------
i7 4770k-4.4 GHz  , GTX 780, 8GO 2400 DDR3, Souris FNATIC, Clavier KBT Pure Pro...
Reply

Marsh Posté le 02-05-2010 à 16:53:27    

A mon avis t'es arrivé au bout des optimisations possibles ...
Essaye un raid0 , ou bien essaye une autre distro (genre ubuntu ou mandriva live cd),  refais le test, et tu verras peut être une différence ... pask'avec une machine comme la tienne, tu ne devrais avoir aucun pb de perf même sans aucun optimisation ...


Message édité par [Albator] le 02-05-2010 à 16:55:45
Reply

Marsh Posté le 02-05-2010 à 17:43:45    


 
Je refais les manipulations avec un Chunk à 512 ko et je te tiens au courant dès demain, au pire je changerai d'OS pour tester également, j'ai le temps  :)  
 
++


---------------
i7 4770k-4.4 GHz  , GTX 780, 8GO 2400 DDR3, Souris FNATIC, Clavier KBT Pure Pro...
Reply

Marsh Posté le 03-05-2010 à 08:51:02    

Me revoilà de bon matin ! Une fois la reconstruction et le formatage terminée, voici les résultats surprenant :
 

Citation :

SERVEUR:/home/flust# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]  
md0 : active raid5 sdd1[2] sdc1[1] sdb1[0]
      2930271232 blocks level 5, 512k chunk, algorithm 2 [3/3] [UUU]
      bitmap: 0/175 pages [0KB], 4096KB chunk
 
unused devices: <none>
 
SERVEUR:/home/flust# mkfs.ext4 -b 4096 -E stride=32,stripe-width=64 /dev/md0
mke2fs 1.41.3 (12-Oct-2008)
Étiquette de système de fichiers=
Type de système d'exploitation : Linux
Taille de bloc=4096 (log=2)
Taille de fragment=4096 (log=2)
183148544 i-noeuds, 732567808 blocs
36628390 blocs (5.00%) réservés pour le super utilisateur
Premier bloc de données=0
Nombre maximum de blocs du système de fichiers=0
22357 groupes de blocs
32768 blocs par groupe, 32768 fragments par groupe
8192 i-noeuds par groupe
Superblocs de secours stockés sur les blocs :  
 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,  
 4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,  
 102400000, 214990848, 512000000, 550731776, 644972544
 
Écriture des tables d'i-noeuds : complété                        
Création du journal (32768 blocs) : complété
Écriture des superblocs et de l'information de comptabilité du système de
fichiers : complété
 
Le système de fichiers sera automatiquement vérifié tous les 32 montages ou
après 180 jours, selon la première éventualité. Utiliser tune2fs -c ou -i
pour écraser la valeur.
 
SERVEUR:/home/flust# tune2fs -E test_fs /dev/md0
 
SERVEUR:/home/flust# tune2fs -l /dev/md0 |grep flags
 
SERVEUR:/home/flust# mount /dev/md0 /mnt/raid
 
SERVEUR:/home/flust# dd if=/dev/zero of=/mnt/raid/test.bidon bs=4096 count=100000
100000+0 enregistrements lus
100000+0 enregistrements écrits
409600000 bytes (410 MB) copied, 6,03164 s, 67,9 MB/s


 
malheureusement, en démarrant mon serveur ce matin, je n'avais plus les même résultats (ci-dessous), je tente encore un formatage en ext3 et je vais faire comme tu me l'indique, changer de distribution et m'orienter vers Ubuntu dès ce soir.
 

Citation :


SERVEUR:/home/flust# dd if=/dev/zero of=/mnt/raid/test.bidon bs=4096 count=1000000
1000000+0 enregistrements lus
1000000+0 enregistrements écrits
4096000000 bytes (4,1 GB) copied, 150,137 s, 27,3 MB/s


 
EDIT :
 
Suite à un formatage en Ext3 les résultats sont encore plus décevant :
 

Citation :

SERVEUR:/home/flust# blockdev --setra 16384 /dev/md0
SERVEUR:/home/flust# echo 8192 > /sys/block/md0/md/stripe_cache_size
SERVEUR:/home/flust#  dd if=/dev/zero of=/mnt/raid/test.bidon bs=4096 count=1000000
1000000+0 enregistrements lus
1000000+0 enregistrements écrits
4096000000 bytes (4,1 GB) copied, 209,543 s, 19,5 MB/s


 
Dès ce soir je tente Ubuntu ... je vous tiens au courant et je garde espoir !

Message cité 1 fois
Message édité par mlevain le 03-05-2010 à 11:40:58

---------------
i7 4770k-4.4 GHz  , GTX 780, 8GO 2400 DDR3, Souris FNATIC, Clavier KBT Pure Pro...
Reply

Marsh Posté le 03-05-2010 à 18:28:21    

mlevain a écrit :

Citation :

...409600000 bytes (410 MB) copied, 6,03164 s, 67,9 MB/s



mlevain a écrit :

Citation :

...4096000000 bytes (4,1 GB) copied, 150,137 s, 27,3 MB/s



 
 [:cosmoschtroumpf]

Reply

Marsh Posté le 03-05-2010 à 21:54:16    


 
Rassure toi je n'y comprends rien non plus, j'ai télécharger le DVD de Ubuntu pour changer de Debian, lors de l'installation il ne détecte plus mon disque sur lequel était Debian ... je retélécharge l'image... ca comment bien :-) je vous tien au courant dès que mon raid 5 sous Ubuntu sera sur pied


---------------
i7 4770k-4.4 GHz  , GTX 780, 8GO 2400 DDR3, Souris FNATIC, Clavier KBT Pure Pro...
Reply

Marsh Posté le 18-05-2010 à 15:37:07    

Salut,
 
J'ai la même config :  
- Pentium dual core E5200 (2.5Ghz)  
- 4 Go DDR2 6400  
- Carte mère Gygabite GA-G31M-ES2L  
- 1x 80Go (pour DEBIAN)  
- 3x 1 To Samsung 7200Tr/min
 
Je tourne en debian lenny + xen et je suis tout juste en train de syncro mon raid ;)

Code :
  1. Personalities : [raid6] [raid5] [raid4]
  2. md0 : active raid5 sdb1[0] sdd1[3] sdc1[1]
  3.       1953519872 blocks level 5, 64k chunk, algorithm 2 [3/2] [UU_]
  4.       [===>.................]  recovery = 18.0% (176307756/976759936) finish=147
  5. .2min speed=90581K/sec



Message édité par Nasga le 18-05-2010 à 15:37:59
Reply

Marsh Posté le 18-05-2010 à 15:52:54    

Salut !
 
Pendant la synchronisation j'ai les meme performances, c'est une fois le RAID monté et partagé avec windows que je rencontre des problèmes de vitesse d'écriture et de lecture.
 
Je suis actuellement entrain de refaire mon raid sous Ubuntu, après avoir testé Mandriva 2010 et débian, je rédigerai les différentes étapes que j'ai suivis très prochainement, pour le moment sur ubuntu ca donne ca :
 

Citation :

root@SERVEUR:~# dd if=/dev/zero of=/home/flust/RAID/test.bidon bs=4096 count=1000000
1000000+0 enregistrements lus
1000000+0 enregistrements écrits
4096000000 octets (4,1 GB) copiés, 53,5442 s, 76,5 MB/s


 
Ce qui est nettement plus intéressant que mes précèdent essais,
 
++


---------------
i7 4770k-4.4 GHz  , GTX 780, 8GO 2400 DDR3, Souris FNATIC, Clavier KBT Pure Pro...
Reply

Marsh Posté le 18-05-2010 à 18:56:44    

Code :
  1. dd if=/dev/zero of=/media/raid5/fichier.test bs=4096 count=1000000
  2. 1000000+0 records in
  3. 1000000+0 records out
  4. 4096000000 bytes (4.1 GB) copied, 26.808 s, 153 MB/s


 
Raid 5 (géré par un dom0 paravirtualisé avec 128Mo de mémoire) formaté en xfs.
 
Combien tu fait sur un disque simple ? je tournais à plus de 100Mo/s de mon seven vers mon partage samba (utilisation max du réseau), maintenant je suis entre 70 et 80Mo/s...
Je viens de constater que le raid5 logiciel bouffe énormément de CPU sur ma config (donc sur la tienne aussi...).


Message édité par Nasga le 18-05-2010 à 20:48:57
Reply

Marsh Posté le 19-05-2010 à 08:30:09    

Mes disques ont de bonnes performances, mais ca reste des 5400tr/min
 
Ce sont les modèle 1.5To WD 64mo de cache, lors de la reconstruction du raid ils affichent 95Mo/s donc c'est effectivement la vitesse qu'il peuvent atteindre. dès que mon  nouveau raid est près je transmettrai les testes via le gestionnaire de disque de Ubuntu,
 
++


---------------
i7 4770k-4.4 GHz  , GTX 780, 8GO 2400 DDR3, Souris FNATIC, Clavier KBT Pure Pro...
Reply

Marsh Posté le 19-05-2010 à 09:55:32    

De mon coté, je vais tester le raid sur mon dom0 afin d'écarter tout problème de perf lié à la virtualisation.

Reply

Marsh Posté le 20-05-2010 à 13:34:09    

Pour information voici les performance de mon RAID 5 :
 
http://img10.hostingpics.net/pics/246764PerfRAID5.jpg
 

Citation :

root@SERVEUR:~# dd if=/dev/zero of=/home/flust/RAID/test.bidon bs=4096 count=1000000
1000000+0 enregistrements lus
1000000+0 enregistrements écrits
4096000000 octets (4,1 GB) copiés, 53,5442 s, 76,5 MB/s


 
++


Message édité par mlevain le 20-05-2010 à 13:35:58
Reply

Marsh Posté le 05-02-2011 à 01:53:00    

mlevain a écrit :

Salut !
 
Pendant la synchronisation j'ai les meme performances, c'est une fois le RAID monté et partagé avec windows que je rencontre des problèmes de vitesse d'écriture et de lecture.
 
Je suis actuellement entrain de refaire mon raid sous Ubuntu, après avoir testé Mandriva 2010 et débian, je rédigerai les différentes étapes que j'ai suivis très prochainement, pour le moment sur ubuntu ca donne ca :
 

Citation :

root@SERVEUR:~# dd if=/dev/zero of=/home/flust/RAID/test.bidon bs=4096 count=1000000
1000000+0 enregistrements lus
1000000+0 enregistrements écrits
4096000000 octets (4,1 GB) copiés, 53,5442 s, 76,5 MB/s


 
Ce qui est nettement plus intéressant que mes précèdent essais,
 
++


 
Etant exactement dans le même cas et encore débutant au niveau Raid linux, est-ce que la fameuse rédaction des étapes promises sont disponibles quelque part?
Sur un une plateforme amd avec 3 WD 1.5To (5400rpm) en raid5, LVM et partition XFS en faisant attention (je crois) à faire correspondre les chunks sizes et le nombre de stripes, j'ai des vitesses de l'ordre de 115MB/s en lecture mais seulement 26MB/s en écriture, ce qui me semble tout de même un peu ridicule!
Les deux cores ne sont même pas maxed out, alors je vois pas vraiment où est le problème.
 
Merci encore pour toutes ces belles informations en tout cas!
 
edit:  
bon en fait en changeant de carte mère et donc de proc (opteron 1.8ghz => core2duo a 3ghz, bus IDE sur pciEx au lieu de pci, etc) les perfs sont beaucoup plus normales, 160MB/s en écriture avec 8192 en stripe_cache_size. Je suppose que c'était un problème de bus sur la carte précédente.
Qu'est-ce que j'apprends en ce moment ...  :sweat:


Message édité par zeflash le 07-02-2011 à 13:13:44
Reply

Marsh Posté le 15-02-2011 à 15:08:34    

Salut !
 
Effectivement je l'avais promise et je ne l'ai pas fait ... j'en suis désolé car aujourd'hui je ne m'en souviens plus vraiment et je n'ai pas trop le temps de me replongé dans les config de mon ancien RAID... et oui, aujourd'hui je tourne sous SYNOLOGY DS-1511+ ... une vrai bête en terme de performances mais à un prix exorbitant je l'avoue ! Ceci dit mon RAID sous Linux tourne encore, mais arrivé au 3/4 de remplissage ce dernier me posait vraiment de gros problème en lecture tout comme en écriture, pendant une copie par exemple je passais de 55Mb/s à 2 ou 3Mb/s !!! Du coup mon transfert de fichier prenait un temps fou ! Enfin bref, de l'histoire ancienne désormais pour moi :-)
 
C'était une bonne expérience lorsque mes moyens étaient limités,
 
Bonne continuation

Reply

Marsh Posté le 10-06-2012 à 10:28:18    

Je déterre un peu le sujet, mais je tenais à remercier tout le monde pour ce poste qui m'a bien aidé.
 
J'ai une config en Atom D525 avec 1Go de RAM et 4 DD de 2To. Impossible de dépasser les 50Mo en lecture/écriture sur un RAID 5. J'ai changé les chunk size et rien n'y fait.
 
Bref, je suis parti sur un RAID 1 (2 x 2To) et les deux autres disques ne sont pas en RAID.  
 
Pour info, je suis sous Debian x64. J'ai essayé la dernière version de FreeNAS (8.0.4-RELEASE-p2-x86) avec un RAID en ZFS... Ce n'était pas mieux.
 
Alors, peut-être que l'Atom n'est pas assez solide pour faire du RAID 5 logiciel (j'en doute, puisque le proc n'est jamais à donf). Par contre, je rejoins l'idée de zeflash, concernant la "qualité" des contrôleurs.
 
Sinon, petit info : Un Intel Atom D525 (ZOTAC MOT NM10-DTX F ATOM D525 WIFI DDR2 mini-DTX NM10) n'arrive pas à dépasser les 70Mo/sec en transfert réseau. Avec une AMD Fusion, j'arrive à plafonner le Gigabite soit 110 Mo/sec (bon OK normalement, c'est 120Mo/sec :))


Message édité par brutux le 10-06-2012 à 10:28:55
Reply

Marsh Posté le 12-06-2012 à 11:33:29    

Reste aussi à tester avec une Debian plus récente (Wheezy), qui aura un noyau plus récent au passage (3.2), avec un lot d'amélioration non négligeable pour le file system, ainsi qu'éventuellement de meilleurs drivers réseau.


---------------
Spécialiste du bear metal
Reply

Marsh Posté le 12-06-2012 à 15:54:53    

Ben, FreeNAS repose sur une BSD et le résultat n'était pas "probant"... Franchement, je ne comprends pas ce qu'il cloche.  
 
Dans mon cas, chaque disque était dans les 100Mo/s. tu fais un RAID et hop, 50Mo/s (encore... ca descend avec le temps)...  
Le processeur ne tourne pas à fond, la RAM est correcte...  
 
Soit c'est logiciel, comme tu le disais dans ton message, soit les chipset SATA sont vraiment des merdes ! :)


Message édité par brutux le 12-06-2012 à 15:55:13
Reply

Marsh Posté le 12-06-2012 à 22:04:32    

À tester avec un autre controleur SATA sinon, le chip merdique n'étant pas à exclure en effet.


---------------
Spécialiste du bear metal
Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed