MySQL/InnoDB sur du RAID6

3 réponses

Auteur	Message
Bool \| Modérateur Inscrit le : 09/05/2005	# Le 01/10/2012 à 10:07 Dans les divers docs (et mailing list OVH) on évoque souvent l'overhead qu'implique le RAID6, sans pour autant le quantifier. Ayant deux serveurs en production qui semblaient justement plombés par le RAID, j'ai donc essayé de mesurer ça. Le contexte : dans les deux cas il s'agit d'un RAID6 de 12 SSD, géré en software par le kernel Linux (via md). J'ai abandonné l'approche hardware, la carte ne suivait pas et les débits étaient 50% plus faibles (une LSI MegaRAID SAS 9260-4i, avec BBU). Sur ces grapes sont stockées essentiellement des VM Xen, faisant tourner du MySQL (environ 1To de BDD en InnoDB). La particularité de MySQL/InnoDB est de générer essentiellement des écritures aléatoires de 8Ko seulement. Qu'est-ce que je mesure ? Avec iostat on peut voir les lectures et écritures que le système envoi vers la couche RAID, ainsi que les lectures et écritures que la couche RAID envoi vers les disques physiques. Et c'est donc ce que je reporte ici. J'ai donc un premier serveur, le serveur A, qui utilise des chunk de 128Ko, c'est à dire la taille recommandée pour les perfs et la longévité des SSD en question (des Intel). Sur ce serveur, sur la couche RAID j'ai donc : \| IO/s \| Ko lus/s \|Ko écr./s \| ----------+----------+----------+----------+ md* \| 2015,45 \| 7439,13 \| 11753,99 \| Voyons comment ça se traduit «physiquement» : \| IO/s \| Ko lus/s \|Ko écr./s \| ----------+----------+----------+----------+ sda \| 989,89 \| 4943,84 \| 2007,47 \| sdb \| 992,71 \| 4921,75 \| 2010,37 \| sdc \| 1006,03 \| 4797,13 \| 2154,84 \| sdd \| 1022,96 \| 4789,56 \| 2266,61 \| sdf \| 1035,42 \| 4672,81 \| 2434,97 \| sde \| 1035,03 \| 4740,99 \| 2307,19 \| sdh \| 1038,79 \| 4696,72 \| 2408,6 \| sdg \| 1037,31 \| 4640,32 \| 2474,62 \| sdi \| 1033,39 \| 4704,68 \| 2490,09 \| sdj \| 1022,89 \| 4622,09 \| 2441,75 \| sdk \| 1022,06 \| 4692 \| 2284,07 \| sdl \| 1041,32 \| 4883,74 \| 2120,82 \| ----------+----------+----------+----------+ total \| 12277,8 \| 57105,63 \| 27401,4 \| Ce qui nous donne ce joli ratio : \| IO/s \| Ko lus/s \|Ko écr./s \| ----------+----------+----------+----------+ md* \| 2015,45 \| 7439,13 \| 11753,99 \| physique \| 12277,8 \| 57105,63 \| 27401,4 \| ----------+----------+----------+----------+ total \| 609,18% \| 767,64% \| 233,12% \| => Pour ma part j'interprète ces chiffres de cette façon : pour atteindre les 2000 IO/s demandés par le système, la couche RAID6 est contrainte de générer 12'000 IO/s (en moyenne 1000 par disque) ! Si on se base uniquement sur les IO/s, le fait d'avoir 12 disques au lieu d'un seul ne permettrait donc que de doubler les perfs... N'obtenant pas les performances attendues j'ai donc tenté une configuration différente sur le serveur B, qui pour le coup utilise des chunk de 8Ko, correspondant un peu plus à ce que demande MySQL, mais malmenant les SSD (c'est à dire que peu importe les chiffres ici, les perfs des SSD seront amoindries). Je vous donne directement le récap du serveur B : \| IO/s \| Ko lus/s \|Ko écr./s \| ----------+----------+----------+----------+ md* \| 1928,11 \| 4291,02 \| 11384,74 \| physique \| 6879,95 \| 23554,16 \| 18331,39 \| ----------+----------+----------+----------+ total \| 356,82% \| 548,92% \| 161,02% \| => Les ratios sont un peu meilleurs : l'overhead coté IO/s n'est plus que de 250% ; c'est à dire que pour atteindre les 1900 IO/s demandés par le système, la couche RAID6 est contrainte de générer près de 7'000 IO/s (en moyenne 570 IO/s). Là encore si on se base uniquement sur les IO/s, le fait d'avoir 12 disques au lieu d'un seul permettrait de multiplier les perfs par trois uniquement. Ce surcoût du RAID6 vient du fait qu'il travaille par blocs, et que ces blocs sont très gros. Ici avec 12 disques, j'ai dans le premier cas des blocs de 1280Ko ((12 disques - 2 disques de parités) * 128Ko), et dans le second des blocs de 80Ko. Et donc, pour que MySQL puisse écrire 8Ko dans un bloc, le système RAID doit d'abord lire le bloc en entier (les 1280Ko dans le cas du serveur A), modifier ce bloc en mémoire, puis ré-écrire la totalité des 1280Ko. Dans le pire des cas on se retrouve donc avec 1280Ko lus + 1280Ko écrits, soit un traitement 300 fois plus lent que prévu... Je n'ai pas de chiffres pour le RAID5, mais théoriquement le principe est le même, avec un seul disque de parité. Les performances risquent donc d'être similaires. La solution ? Pour ma part je ne l'ai pas encore trouvée. Certains d'entre vous ont de gros besoins en IO (Dob ?) et ont peut-être fait des tests similaires, voir trouvé une meilleure solution. De mon coté je commence des tests en confiant le RAID à Btrfs, qui gère ça assez différemment. Les écritures devraient être très optimisées, mais les lectures seront très fragmentées... à voir ce que ça donne sur du SSD. daevel : infogérance et conseil \|\| moi
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 01/10/2012 à 10:21 A titre de comparaison, sur un RAID10 de 4 SSD (chunks de 512Ko) : \| IO/s \| Ko lus/s \|Ko écr./s \| ----------+----------+----------+----------+ md* \| 681,82 \| 1986,66 \| 1648,25 \| physique \| 423,97 \| 2107,28 \| 3274,82 \| ----------+----------+----------+----------+ total \| 62,18% \| 106,07% \| 198,68% \| Ici il y a moins d'IO, c'est probablement lié à l'ordonnanceur CFQ qui fausse les mesures. Mais si on se base sur les lectures, ainsi que sur les écritures, les ratios sont plutôt très bon (pour du RAID10, 100% est le meilleur ratio en lecture, et 200% est le meilleur ratio en écriture... bizarre qu'on ait légèrement moins). Mais ici, malgré une taille de bloc totale d'1Mo, et une charge MySQL uniquement, je ne retrouve pas le phénomène d'écritures aléatoires... à moins que cela vienne du fait qu'il n'y ait pas de disque de parité, et donc pas besoin de ré-écrire tout le bloc ? daevel : infogérance et conseil \|\| moi
devtribu \| Olivier Modérateur Inscrit le : 16/06/2005	# Le 01/10/2012 à 10:28 Salut Bool, honnetement tout ca me depasse completement Mais je me demande si un raid 10 ne sera pas toujours meilleur en perf que les raid complexes 5/6 ? J'ai migré mon nas de l'entreprise de raid5 a 10 et les perf sont infiniment meilleures Ca doit etre le cas sur du mysql aussi non ? Février 2019, mon futur livre Tout JavaScript chez Dunod https://amzn.to/2PoLd0f
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 02/10/2012 à 13:39 Non non, je ne suis pas non plus à fond là, heureusement d'ailleurs. Là c'est de la production. Ce que je veux dire c'est que pour gérer 2000 iops "réelles", les SSD se mangent 1000 iops chacun, malgré le fait d'avoir 12 disques, alors que je m'attendais à du 250/300 par exemple. En simplifiant à l'extrême, avec 4 SSD en RAID10, j'aurais probablement les mêmes perfs que mes 12 SSD en RAID6. => conclusion, le RAID6 sur SSD ça pue, en tous cas pour du MySQL, et donc faut que je change ça. Il me semble que tu as de gros besoins en iops toi aussi. T'as résolu ça comment ? N serveurs avec un simple RAID1 de SSD ? daevel : infogérance et conseil \|\| moi

Auteur

Message

Bool |
Modérateur

Inscrit le : 09/05/2005

# Le 01/10/2012 à 10:07

Dans les divers docs (et mailing list OVH) on évoque souvent l'overhead qu'implique le RAID6, sans pour autant le quantifier.
Ayant deux serveurs en production qui semblaient justement plombés par le RAID, j'ai donc essayé de mesurer ça.

Le contexte : dans les deux cas il s'agit d'un RAID6 de 12 SSD, géré en software par le kernel Linux (via md). J'ai abandonné l'approche hardware, la carte ne suivait pas et les débits étaient 50% plus faibles (une LSI MegaRAID SAS 9260-4i, avec BBU).
Sur ces grapes sont stockées essentiellement des VM Xen, faisant tourner du MySQL (environ 1To de BDD en InnoDB). La particularité de MySQL/InnoDB est de générer essentiellement des écritures aléatoires de 8Ko seulement.

Qu'est-ce que je mesure ? Avec iostat on peut voir les lectures et écritures que le système envoi vers la couche RAID, ainsi que les lectures et écritures que la couche RAID envoi vers les disques physiques. Et c'est donc ce que je reporte ici.

J'ai donc un premier serveur, le serveur A, qui utilise des chunk de 128Ko, c'est à dire la taille recommandée pour les perfs et la longévité des SSD en question (des Intel).
Sur ce serveur, sur la couche RAID j'ai donc :

          |     IO/s | Ko lus/s |Ko écr./s |

----------+----------+----------+----------+

md*       |  2015,45 |  7439,13 | 11753,99 |

Voyons comment ça se traduit «physiquement» :

          |     IO/s | Ko lus/s |Ko écr./s |

----------+----------+----------+----------+

sda       |   989,89 |  4943,84 |  2007,47 |

sdb       |   992,71 |  4921,75 |  2010,37 |

sdc       |  1006,03 |  4797,13 |  2154,84 |

sdd       |  1022,96 |  4789,56 |  2266,61 |

sdf       |  1035,42 |  4672,81 |  2434,97 |

sde       |  1035,03 |  4740,99 |  2307,19 |

sdh       |  1038,79 |  4696,72 |  2408,6  |

sdg       |  1037,31 |  4640,32 |  2474,62 |

sdi       |  1033,39 |  4704,68 |  2490,09 |

sdj       |  1022,89 |  4622,09 |  2441,75 |

sdk       |  1022,06 |  4692    |  2284,07 |

sdl       |  1041,32 |  4883,74 |  2120,82 |

----------+----------+----------+----------+

total     | 12277,8  | 57105,63 | 27401,4  |

Ce qui nous donne ce joli ratio :

          |     IO/s | Ko lus/s |Ko écr./s |

----------+----------+----------+----------+

md*       |  2015,45 |  7439,13 | 11753,99 |

physique  | 12277,8  | 57105,63 | 27401,4  |

----------+----------+----------+----------+

total     |  609,18% |  767,64% |  233,12% |

=> Pour ma part j'interprète ces chiffres de cette façon : pour atteindre les 2000 IO/s demandés par le système, la couche RAID6 est contrainte de générer 12'000 IO/s (en moyenne 1000 par disque) ! Si on se base uniquement sur les IO/s, le fait d'avoir 12 disques au lieu d'un seul ne permettrait donc que de doubler les perfs...

N'obtenant pas les performances attendues j'ai donc tenté une configuration différente sur le serveur B, qui pour le coup utilise des chunk de 8Ko, correspondant un peu plus à ce que demande MySQL, mais malmenant les SSD (c'est à dire que peu importe les chiffres ici, les perfs des SSD seront amoindries).

Je vous donne directement le récap du serveur B :

          |     IO/s | Ko lus/s |Ko écr./s |

----------+----------+----------+----------+

md*       |  1928,11 |  4291,02 | 11384,74 |

physique  |  6879,95 | 23554,16 | 18331,39 |

----------+----------+----------+----------+

total     |  356,82% |  548,92% |  161,02% |

=> Les ratios sont un peu meilleurs : l'overhead coté IO/s n'est plus que de 250% ; c'est à dire que pour atteindre les 1900 IO/s demandés par le système, la couche RAID6 est contrainte de générer près de 7'000 IO/s (en moyenne 570 IO/s). Là encore si on se base uniquement sur les IO/s, le fait d'avoir 12 disques au lieu d'un seul permettrait de multiplier les perfs par trois uniquement.

Ce surcoût du RAID6 vient du fait qu'il travaille par blocs, et que ces blocs sont très gros. Ici avec 12 disques, j'ai dans le premier cas des blocs de 1280Ko ((12 disques - 2 disques de parités) * 128Ko), et dans le second des blocs de 80Ko.
Et donc, pour que MySQL puisse écrire 8Ko dans un bloc, le système RAID doit d'abord lire le bloc en entier (les 1280Ko dans le cas du serveur A), modifier ce bloc en mémoire, puis ré-écrire la totalité des 1280Ko. Dans le pire des cas on se retrouve donc avec 1280Ko lus + 1280Ko écrits, soit un traitement 300 fois plus lent que prévu...

Je n'ai pas de chiffres pour le RAID5, mais théoriquement le principe est le même, avec un seul disque de parité. Les performances risquent donc d'être similaires.

La solution ? Pour ma part je ne l'ai pas encore trouvée. Certains d'entre vous ont de gros besoins en IO (Dob ?) et ont peut-être fait des tests similaires, voir trouvé une meilleure solution.
De mon coté je commence des tests en confiant le RAID à Btrfs, qui gère ça assez différemment. Les écritures devraient être très optimisées, mais les lectures seront très fragmentées... à voir ce que ça donne sur du SSD.

daevel : infogérance et conseil || moi

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 01/10/2012 à 10:21

A titre de comparaison, sur un RAID10 de 4 SSD (chunks de 512Ko) :

          |     IO/s | Ko lus/s |Ko écr./s |

----------+----------+----------+----------+

md*       |   681,82 |  1986,66 |  1648,25 |

physique  |   423,97 |  2107,28 |  3274,82 |

----------+----------+----------+----------+

total     |   62,18% |  106,07% |  198,68% |

Ici il y a moins d'IO, c'est probablement lié à l'ordonnanceur CFQ qui fausse les mesures.
Mais si on se base sur les lectures, ainsi que sur les écritures, les ratios sont plutôt très bon (pour du RAID10, 100% est le meilleur ratio en lecture, et 200% est le meilleur ratio en écriture... bizarre qu'on ait légèrement moins).

Mais ici, malgré une taille de bloc totale d'1Mo, et une charge MySQL uniquement, je ne retrouve pas le phénomène d'écritures aléatoires... à moins que cela vienne du fait qu'il n'y ait pas de disque de parité, et donc pas besoin de ré-écrire tout le bloc ?

daevel : infogérance et conseil || moi

devtribu | Olivier
Modérateur

Inscrit le : 16/06/2005

# Le 01/10/2012 à 10:28

Salut Bool,

honnetement tout ca me depasse completement

Mais je me demande si un raid 10 ne sera pas toujours meilleur en perf que les raid complexes 5/6 ?
J'ai migré mon nas de l'entreprise de raid5 a 10 et les perf sont infiniment meilleures
Ca doit etre le cas sur du mysql aussi non ?

Février 2019, mon futur livre Tout JavaScript chez Dunod https://amzn.to/2PoLd0f

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 02/10/2012 à 13:39

Non non, je ne suis pas non plus à fond là, heureusement d'ailleurs. Là c'est de la production.

Ce que je veux dire c'est que pour gérer 2000 iops "réelles", les SSD se mangent 1000 iops chacun, malgré le fait d'avoir 12 disques, alors que je m'attendais à du 250/300 par exemple.

En simplifiant à l'extrême, avec 4 SSD en RAID10, j'aurais probablement les mêmes perfs que mes 12 SSD en RAID6.

=> conclusion, le RAID6 sur SSD ça pue, en tous cas pour du MySQL, et donc faut que je change ça.

Il me semble que tu as de gros besoins en iops toi aussi. T'as résolu ça comment ? N serveurs avec un simple RAID1 de SSD ?

daevel : infogérance et conseil || moi

Répondre

Vous ne pouvez pas participer au forum, car votre inscription n'a pas été validée. Pour vous faire valider en tant que Membre, cliquez ici.