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

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.

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!

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.

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).

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.

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.