Dans cette suite de ma série "Réglage des performances par réflexe", j'aimerais discuter des disques à semi-conducteurs (SSD) et de certains des problèmes que je vois avec leur utilisation dans un environnement SQL Server. Pour une description détaillée des SSD, consultez cet article de Wikipédia.
Que font les SSD pour les performances de SQL Server ?
Les SSD n'ont pas de pièces mobiles, donc lorsqu'une lecture ou une écriture se produit, il n'y a presque pas de latence d'E/S. La latence d'un disque qui tourne provient de deux éléments :
- Déplacement de la tête de disque vers la bonne piste sur la surface du disque (connu sous le nom de temps de recherche)
- Attendre que le disque tourne au bon endroit sur la piste (connu sous le nom de latence de rotation)
Cela signifie que les SSD offrent une amélioration considérable des performances en cas de goulot d'étranglement d'E/S.
C'est aussi simple que ça.
Il y a une petite complication qui mérite d'être mentionnée, mais qui dépasse le cadre de cet article pour approfondir :les performances du SSD peuvent commencer à se dégrader lorsque le disque est vraiment plein (étudié et expliqué en détail dans cet article d'AnandTech). Il peut également y avoir de la mémoire système requise pour le pilote SSD pour aider au nivellement de l'usure (prolonger la durée de vie des cellules NAND dans le SSD), et cela va varier selon le fournisseur. Assez de cela - revenons aux trucs de SQL Server.
Évitez les mauvais conseils Internet
Il y a deux très mauvais conseils que je vois sur Internet concernant SQL Server et les SSD.
Le premier concerne ce qu'il faut mettre sur le SSD, où le conseil est de toujours mettre tempdb et vos journaux de transactions sur des SSD. À première vue, cela semble être un bon conseil, car les journaux de transactions et tempdb sont généralement des goulots d'étranglement dans le système.
Et s'ils ne le sont pas ?
Votre charge de travail peut être principalement en lecture, auquel cas le journal des transactions ne sera probablement pas un goulot d'étranglement de la charge de travail et donc le mettre sur un SSD peut être un gaspillage d'un SSD coûteux.
Votre tempdb peut ne pas être beaucoup utilisé par votre charge de travail, donc le mettre sur un SSD peut être un gaspillage d'un SSD coûteux.
Lorsque vous réfléchissez à la partie de l'environnement SQL Server à déplacer vers le SSD, vous souhaitez rechercher où se trouvent les goulots d'étranglement d'E/S. Cela peut être fait très facilement en utilisant le code que j'ai posté la semaine dernière qui utilise le DMV sys.dm_io_virtual_file_stats pour fournir un instantané des latences d'E/S pour tous les fichiers de toutes les bases de données de l'instance. Pour donner un sens à vos chiffres de latence et les comparer aux bonnes/mauvaises valeurs, lisez ce long article que j'ai écrit spécifiquement sur les latences d'E/S de tempdb et du journal des transactions.
Et puis même si vous avez des latences élevées, ne vous précipitez pas et pensez que la seule solution est de déplacer le(s) fichier(s) peu performant(s) vers un SSD :
- Pour les latences de lecture des fichiers de données, recherchez pourquoi il y a autant de lectures. Je couvre ça ici.
- Pour les latences d'écriture des fichiers journaux, envisagez toutes les façons d'ajuster les performances du journal et ce qui est consigné. Je couvre cela ici, ici et ici.
Le pire cas possible est celui où vous recevez un tas de disques SSD, suivez les conseils Internet pour déplacer tempdb et vos fichiers journaux vers eux, et il n'y a alors aucun gain de performances de charge de travail. Cela n'encouragera pas votre direction à vous fournir des SSD plus chers.
Le deuxième mauvais conseil concerne la fragmentation des index, où le conseil est que, comme les SSD sont si rapides, vous n'avez pas à vous soucier de la fragmentation des index lorsque vous utilisez des SSD.
Quelle bêtise !
Je réfute ce mauvais conseil de trois manières :
- Les disques SSD n'arrêtent en aucun cas la cause de la fragmentation de l'index :les fractionnements de pages à partir des pages nécessitant de l'espace libre pour une insertion aléatoire ou une augmentation de la taille des lignes. Un fractionnement de page génère la même quantité de journal des transactions, d'utilisation des ressources et d'attentes de thread potentielles, quel que soit l'endroit où les fichiers de données/journaux sont stockés.
- La fragmentation d'index implique d'avoir de nombreuses pages de données/d'index avec une faible densité de pages (c'est-à-dire beaucoup d'espace vide et libre). Voulez-vous vraiment que vos SSD coûteux stockent beaucoup d'espace vide ? Les SSD n'aident pas du tout ici.
- Mon collègue Jonathan Kehayias a mené une enquête approfondie, à l'aide d'Événements étendus, sur les modèles d'E/S autour de la fragmentation d'index spécifiquement pour répondre à ce mauvais conseil et a découvert que la fragmentation d'index lors de l'utilisation de disques SSD continuait de nuire aux performances. Vous pouvez lire son long message ici.
La seule chose que les SSD font autour de la fragmentation d'index est d'accélérer les lectures, donc il y a moins de pénalité de performance pour les analyses de plage d'index lorsque la fragmentation d'index existe, mais le point 3 ci-dessus montre qu'il y a toujours une pénalité.
Les SSD ne changent pas la façon dont vous traitez et/ou empêchez la fragmentation des index dans votre environnement SQL Server.
Assurez-vous de protéger vos données
L'un des péchés capitaux que je vois des gens commettre en utilisant des SSD est d'en utiliser seulement un. Avec un seul disque, quel niveau de RAID utilisez-vous ? Zéro. RAID-0 ne fournit aucune redondance.
Si vous comptez utiliser un SSD, vous devez en utiliser au moins deux, dans une configuration RAID-1 (mise en miroir). Il ne sert à rien d'améliorer les performances si vous sacrifiez la disponibilité du système en échange.
Une réaction que j'arrive parfois à utiliser au moins deux SSD est que la carte SSD fournit deux disques à Windows, et donc créer un volume Windows en miroir sur les deux disques est sûrement le même que RAID-1 sur deux SSD physiquement séparés ?
Non ce n'est pas. C'est toujours un SSD physique, sans redondance. Avez-vous déjà vu la moitié d'une carte SSD tomber en panne ? Non, moi non plus. Faites-le correctement et utilisez-en deux et obtenez une véritable redondance pour vos données.
L'autre réticence que je reçois est qu'il s'agit de disques SSD, et non de disques rotatifs, ils ne vont donc pas échouer. C'est faux. Les SSD peuvent échouer et échouent, tout comme les disques en rotation. J'ai personnellement vu deux SSD de niveau entreprise tomber en panne lors de tests dans notre environnement de laboratoire. Selon cet article sur StorageReview.com, les SSD grand public ont un MTBF de 2 millions d'heures contre 1,5 million d'heures pour les disques rotatifs grand public, et je m'attendrais à des résultats similaires pour les disques d'entreprise, mais les SSD échouent.
Résumé
Ne tombez pas dans le piège de penser que tout ce que vous mettez sur le SSD signifie que vous obtiendrez une amélioration des performances – vous devez choisir avec soin. Et ne croyez pas non plus l'absurdité qui consiste à ignorer la fragmentation des index lors de l'utilisation de disques SSD.
Les SSD sont un moyen très utile d'augmenter les performances, mais pour leur coût, vous voulez vous assurer que vous maximisez le retour sur investissement de votre entreprise en les utilisant correctement et uniquement lorsque cela est approprié.
Dans le prochain article de la série, je discuterai d'une autre cause fréquente de réglage des performances par réflexe. En attendant, bon dépannage !
