Discussion :

[LiTiL_DiViL]

Bonjour,
Un de mes applicatifs métiers dont la base est stockée sur un serveur sql me pose un problème de performance. Après audit et analyse, nous avons repéré des problèmes sur notre applicatif. Ceci dit notre consultant nous a suggérer de déplacer le tempdb et notre base sur un volume SSD afin d'éliminer toute problématique potentielle lié a de la latence et potentiellement booster la performance de notre base.

J'ai donc acheté 4 disques SSD de 200Go pour stocker notre base et notre tempDB. Je souhaiterai avoir quelques suggestions sur la config du RAID 10 5, 6 ou autre (ayant lu a peu près tout et sont contraires sur ce sujet).

Mes bases de données principales font environ 40 Go + 20 Go, et mon tempdb 80 Go.

Voila n'hésitez pas à me faire part de vos remarques et suggestions

[LiTiL_DiViL]

Après réflexion je pense que la meilleur configuration pour moi est une configuration a base de RAID10 j'aurai la meilleur performance et un niveau de sécurité minimum. Même si au final je perd deux disques utiles.

[SQLpro]

Oui, RAID 10...

Voici ce que je dit à ce sujet dans mon livre sur SQL Server à paraître :

PERFORMANCES : utilisez du RAID 0+1 ou du RAID 10 pour les journaux de transactions les plus sollicités (base de production, tempdb...) et du RAID 1 pour les données. Bannissez le RAID 5 ses dérivés 3, 4, 6) et ses combinaisons (50, 60), même pour effectuer des sauvegardes !

Cela dit, avant d'en arriver là, il y a sans doutes d'autres choses à faire... Car si tempdb est fortement sollicité, le SSD ne sera pas la panacée... Pourquoi ?

Re mon livre à paraître :

Disques SSD

On pourrait penser, en termes économiques, qu’un disque de type SSD (Solid State Device) permet de meilleures performances qu’un ensemble de disques magnétiques. C’est vrai dans un sens mais à budget égal et volumétrie comparable, c’est faux :
• les SSD sont encore très chers par rapport aux disques magnétiques ;
• Leurs performances sont instables (très élevées en début de vie, se stabilisant à un niveau plus bas à l’utilisation) ;
• La rétention des informations n’est possible que sur quelques mois (il faut constamment les maintenir en exploitation) ;
• leurs algorithmes de stockage rendent difficiles voire impossibles la récupération de données en cas de panne du disque ;
• l’écriture dans un SSD est bien moins rapide que la lecture, particulièrement dans le cas d’une modification. Or les SGBDR cachent les données en RAM et font donc peu de lectures mais beaucoup d’écritures ;
Tant est si bien qu’actuellement et à même budget, une bonne organisation de disque dur magnétique en RAID 0 bât à plate couture les meilleurs SSD disponibles à ce jour ! Mais le jour est proche ou le SSD remplacera avantageusement leurs ancêtres magnétiques...
Cependant, outre la vitesse de lecture accrue, le disque SSD présente certains avantages dont un bon nombre sont d’ordre écologique :
• moindre consommation d’énergie ;
• énergie dissipée sous forme de chaleur moindre ;
• pas de bruits ni de vibrations.
Notez que le MTBF (temps moyen de bon fonctionnement, en anglais Mean Time Between Failures) autrefois bien plus court sur du SSD a été amélioré en redondant le stockage de manière interne.

PERFORMANCE : dans le cas d’une organisation mixte (SSD + disques magnétiques) préférez pour les bases OLTP placer en premier tempdb en SSD, et pour les bases OLAP, les tables et les index les plus lus.

NOTA : certains fabricants, proposent un stockage contournant le biais du contrôleur de disque en passant par le bus PCI, ce qui accélère encore les accès au stockage (Fusion-io par exemple).

par exemple il est intéressant de savoir si votre tempdb a été correctement dimensionnée au niveau des storages et de leur nombre... Quel est la constitution des fichiers de votre tempdb ?

D'autre parte les cartes fusion IO donnent de meilleurs résultats et à moindre coût dans ce cas parce que le flux est // entre le PCI et les bus disque !!!

A +

[iberserk]

Pensez surtout à jouer sur votre code applicatif... vous avez souvent bien plus à gagner que de tenter de dépenser des milliers d'euros pour compenser la pauvreté du code.

N'y voyez pas la une attaque... ne connaissant pas votre code celui-ci est peu être parfaitement optimisé...

[lohworm]

Bonjour,

Dans le cadre d'une remise à plat d'une architecture SQL SERVER somme toute modeste actuellement (grosso modo deux à trois bases OLTP de 10Go, croissance modérée pour l'instant, mais qui sait de quoi demain sera fait ;-)...), avec deux serveur en mirroring, il a nous a été proposé selon des recommandations MS de mettre sur chaque machine, deux disques, un pour le système et un pour les datas.
Et pour les datas, il a été "recommandé" du SSD en RAID5...

Troublé par les contradictions entre ce qu'on peut lire ici ou là, et ce qui vient d'expert MS, ou pas, je m'interroge :

- en mars 2015, la techno SSD est-elle plus mûre qu'au moment de la rédaction du chapître cité plus haut, ou les réserves restent-elles d'actualité avec la même force ?
- un seul disque en SSD, fait-il l'affaire pour nos volumes, ou comme avec des disques magnétiques, il faut quand même penser ventilation des données, des logs, des tempdb ?
- la techno RAID5 peut-elle être pertinente avec les SSD d'aujourd'hui, ou bien il faut continuer à s'en tenir au RAID 10 ou 0+1 ?

Merci d'avance pour vos retours éclairés,

Laurent

[SQLpro]

Quand vous parlez d'expert MS soyez clair...
S'agit-il de Microsoft France ? (il est extrêmement rare qu'ils interviennent et en général uniquement en avant vente sur des projets corporate..°
S'agit-il de Microsoft Consulting Services (MCS) ? C'est une SSII comme les autres qui engage des petits jeunots et les balance expert après 2h de briefing
S'agit-il de quelqu'un de reconnu à titre d'expert par ses pairs ? Comme c'est le cas par exemple des MVP ?

Parce que la plupart des "jeunots" lisent des bonnes pratiques à leurs clients sans aucune interprétation intellectuelle !

Le fait de séparer les data et les transactions permet de récupérer la base en cas de perte de l'un des disque...
Encore faut-il que les deux soient situées sur des disques physiques différents.
Mais comme les écriture se font de manière synchrone pour le JT et asynchrone pour les data, il est important d'alterner ce placement pour chaque base afin de ventiler les IO.
Autrement dit, lorsque ces jeunots disent stupidement qu'il faut placer tous les journaux sur un disque et toutes les data sur l'autre c'est juste une crétinerie qui montre à quel point ces gens de réfléhissent pas.

Quand au RAID 5 ou au SSD, c'est encore pire comme stupidité. Le RAID 5 est contreperformant. Il permet juste de faire des économies.
Et pour le SSD, à budget équivalent, vous aurez plus de performances avec une batterie de 4 à 8 disque en RAID 10 !

Lisez mon livre pour en savoir plus : www.amazon.fr/dp/2212135920/

A +