SQL Server 2K / 2K5 / 2K8 et disques SSD: optimisations spécifiques?

9

Y a-t-il quelqu'un ici qui exécute SQL Server sur des disques SSD? Avez-vous trouvé des conseils d'optimisation spécifiques? Je m'intéresse spécifiquement aux moyens de réduire la fréquence à laquelle SQL Server effectue de petites opérations d'écriture aléatoire, car ils sont l'ennemi des performances SSD, en particulier les disques SSD MLC.

Il y a bien sûr certaines optimisations évidentes: les données lourdes en lecture devraient être servies à partir du SSD, et les choses lourdes en écriture devraient être laissées aux disques rotatifs traditionnels. Cela inclut naturellement les journaux de transactions!

Avec un budget suffisant, bien sûr, on voudrait utiliser des disques SSD SLC comme le X25-E ou la série Vertex Ex ou diverses offres au niveau de l'entreprise. Mais je suis également intéressé par des conseils qui pourraient bénéficier aux configurations SSD MLC. Je pense que c'est un domaine intéressant. L'un des clients de mes clients a un petit budget et un ensemble de données qui a énormément augmenté et ils sont confrontés à une réécriture complète de près d'une centaine de requêtes afin de maintenir un niveau de performance décent. Cependant, je soupçonne discrètement que moins de 500 $ d'espace RAM et SSD pourraient leur rapporter un gain de performances supérieur à des milliers (voire des dizaines de milliers) de dollars en temps de développement.

sql-server ssd

— John Rose
source

3

Vous ne savez pas ce que vous voulez dire en réduisant le nombre de petites écritures aléatoires effectuées par SQL Server. SQL Server écrit les pages de données uniquement pendant les points de contrôle. Par conséquent, la seule façon de limiter le nombre d'écritures est de modifier l'intervalle de point de contrôle ou de ne pas effectuer autant d'opérations de DIU. Voulez-vous dire autre chose?

Dans toutes les implémentations de SSD que j'ai vues (une poignée), c'est un peu l'inverse de ce que vous proposez - la meilleure utilisation des SSD semble être pour les journaux de transactions et tempdb lourds en écriture - en gros, où est le plus grand I / O goulot d'étranglement du sous-système et collez les SSD dedans - car le temps de recherche et la latence sont réduits à une constante faible.

Consultez ce document de recherche produit par MS (malheureusement pas très détaillé sur les spécificités de SQL Server): Migration du stockage du serveur vers les SSD: analyse des compromis .

J'espère que cela t'aides!

— Paul Randal
source

Merci pour ce lien vers l'article de MS. Il est frustrant de manquer de détails, n'est-ce pas? :) Malheureusement, les petites écritures aléatoires sont en effet quelque chose qui peut donner des ajustements aux SSD. En un mot, même pour une petite écriture (c.-à-d. 4Ko), le SSD doit lire un bloc entier en mémoire, le modifier et le réécrire. C'est comme ça que fonctionne la mémoire flash de génération actuelle. Excellent article de présentation

— John Rose

2

Vous ne pouvez pas modifier les caractéristiques d'E / S des serveurs SQL. Son unité de base d'accès au disque, pour les fichiers de données, est une page de 8 Ko. Il les écrira principalement pendant un point de contrôle, mais les écrira également paresseux quand il le pourra.
SQL n'attend pas que les écritures sur le disque de données se terminent avant de revenir, seules les écritures de journal doivent être terminées. Si vous ne pouvez conserver qu'un seul journal de base de données sur un disque, il s'agira d'écritures séquentielles et ce sera correct sur les disques durs rapides normaux.
La performance atteinte du point de vue de SQL, c'est quand il doit lire les disques. Si vous pouvez lui donner plus de mémoire, SQL conservera plus de pages de données en mémoire, ce qui est plus rapide que n'importe quel type de disque, SSD ou autre. Évidemment, vous pouvez également réduire le nombre de lectures de disque en créant des index appropriés. Je m'attends à ce qu'un SSD aide également à ces lectures car elles sont susceptibles d'être aléatoires et bloquées en attendant que les têtes d'entraînement bougent.
Je ne sais pas de quelle taille de base de données nous parlons ici, mais vous voudrez peut-être jeter un œil à HyperOS. Ils font des disques SATA qui ne sont en fait qu'une charge de bâtons de RAM DDR2, avec un SSD ou un disque de 2,5 pouces comme sauvegarde. Le modèle d'accès du serveur n'aura alors aucune importance. Je ne mettrais cependant pas les journaux sur quelque chose comme ça. Les journaux sont ce qui maintient la cohérence de vos données, ils doivent aller sur un support fiable et malgré son SSD et sa batterie de sauvegarde et le serveur a probablement un UPS, etc., je ne me sentirais toujours pas facile de ne pas avoir mes journaux sur un vrai disque dur dans une sorte de matrice RAID tolérante aux pannes.

— pipTheGeek
source

1

Les petites opérations aléatoires sont l'ennemi des disques traditionnels, en raison de la latence de recherche de tête ... Les SSD sont parfaits pour résoudre exactement ce problème.

Avec de longues opérations séquentielles, les disques standard fonctionnent assez bien, il n'y aurait donc aucun intérêt à utiliser des SSD (du point de vue des performances, bien sûr).

— Massimo
source

2

Les SSD sont fantastiques lors des opérations de lecture aléatoire en raison d'une latence de recherche proche de zéro. Ils sont moins adroits lors des opérations d'écriture aléatoires, car une opération d'écriture SSD implique la lecture d'un bloc flash entier (généralement, 128 Ko), la modification du contenu et la réécriture du bloc entier sur flash. En ce qui concerne les opérations longues et séquentielles, les meilleurs SSD au niveau du consommateur (Intel, OCZ Vertex, Samsung) atteignent bien plus de 200 Mo / s en lecture et 80 Mo-150 Mo en écriture, bien au-dessus de ce qu'un seul disque en rotation peut produire.

— John Rose

Êtes-vous sûr? Je ne comprends pas pourquoi une opération d'écriture devrait impliquer la lecture d'un bloc de données avant de le réécrire ... les données à écrire doivent être dans la mémoire de l'ordinateur, n'est-ce pas?

— Massimo

2

@Massimo: parce que le système d'exploitation n'écrit que quelques octets, mais le SSD fonctionne en unités (pages) de 128 Ko (généralement). Il ne peut écrire qu'une page de 128 Ko, rien de moins, rien de plus. Ainsi, lorsque vous modifiez, disons le milieu d'une page, le lecteur lit la page entière, met à jour le milieu, puis écrit la nouvelle page généralement ailleurs, tout en invalidant l'ancien emplacement.

— Cristian Ciupitu

Cristian Ciupitu a raison. Dans certains SSD, cela est atténué par un cache intégré (tous les lecteurs utilisant le contrôleur Indilinx ont 64 Mo de cache, je crois) et peut-être aussi par la mise en cache en écriture du système d'exploitation, si elle est activée. Cependant, même un cache de 64 Mo a ses limites: pour un serveur de base de données effectuant de nombreuses écritures, 64 Mo peuvent ne pas suffire. Les fabricants de micrologiciels ne publient pas beaucoup de détails, mais on pourrait supposer que les meilleurs firmwares (Intel, Indilinx) effectuent des réorganisations / lots intelligents pour conserver de petites écritures aléatoires dans une page de 128 Ko pour minimiser ce surcoût.

— John Rose

D'après ma compréhension du cache, cela vous fera économiser beaucoup de ces petites écritures qui vous inquiètent tellement. Cela n'a même pas beaucoup d'importance, car les bases de données sont conçues pour effectuer beaucoup de lectures / écritures linéaires. Je parie que le SSD fonctionnerait toujours mieux car c'est une lecture linéaire, pas une lecture séquentielle. Cela signifie qu'il y aura toujours des écarts entre les données et que le SSD supprimerait le temps de recherche.

— Pyrolistical le

0

Pas assez de point ici pour ajouter dans le fil de commentaire, mais si vous définissez la taille de page de la base de données / le nombre de lectures multiples pour quoi que ce soit sur le SSD à un multiple de la taille de page du SSD, cela ne devrait pas être un problème.

Je n'ai pas travaillé sur SQL Server depuis longtemps, donc je ne sais pas si ces options sont disponibles là-bas. J'ai fait Oracle et DB2 au cours des dernières années et cela résoudrait vos préoccupations car la base de données serait correctement adaptée aux caractéristiques du disque.

— Kevin K
source

0

Je recommanderais d'aligner la partition où les fichiers de base de données sont stockés.

Je recommanderais également de décider de ce qui se passe sur RAID 0 pour perf (ldf et TempDB), et de placer les données critiques sur RAID 1 (mdf).

Troisièmement, vous devez vraiment mettre à jour le micrologiciel du lecteur ainsi que le micrologiciel / les pilotes du contrôleur SATA. Ce faisant, vous donnez à la société de matériel informatique et à ses développeurs une chance d'optimiser la performance pour vous.

— GregC
source

RAID 0 ne doit jamais être utilisé pour un serveur de base de données. Si un seul disque tombe en panne, la base de données est arrêtée jusqu'à ce que le disque soit remplacé et que les données manquantes soient restaurées à partir de la bande (cela inclut le journal).

— mrdenny

Dans un monde où l'argent n'est pas un objet, tout devrait fonctionner sur le cache L1 alimenté par batterie. Dans le secteur bancaire, le fichier LDF est tout aussi important que le mdf. Pour le calcul scientifique, MDF est le seul fichier qui doit vraiment être à 100%.

— GregC