Notre base de données d'applications de fournisseurs est très intensive en TempDB.
Le serveur est virtuel (VMWare) avec 40 cœurs et 768 Go de RAM, exécutant SQL 2012 Enterprise SP3.
Toutes les bases de données, y compris TempDB, sont sur un SSD de niveau 1 dans SAN. Nous avons 10 fichiers de données tempdb, chacun pré-développé à 1 Go et ils ne se développent jamais automatiquement. Idem avec le fichier journal de 70 Go. Les indicateurs de trace 1117 et 1118 sont déjà définis.
sys.dm_io_virtual_file_stats affiche plus de 50 téraoctets en lecture / écriture sur les fichiers de données et journaux tempdb au cours du mois dernier, avec un io_stall cumulatif de 250 heures ou 10 jours.
Nous avons déjà réglé le code du fournisseur et les SP au cours des 2 dernières années.
Maintenant, nous pensons à placer des fichiers tempdb sur RAM Drive car nous avons une tonne de mémoire. Étant donné que tempdb est détruit / recréé lors du redémarrage du serveur, il s'agit d'un candidat idéal à placer sur la mémoire volatile qui est également éliminée lors du redémarrage du serveur.
J'ai testé cela sur un environnement inférieur et cela a entraîné des temps de requête plus rapides mais une utilisation accrue du processeur, car le processeur fait plus de travail au lieu d'attendre sur un lecteur tempdb lent.
Quelqu'un d'autre a-t-il mis sa tempdb sur la RAM dans des systèmes de production à haut niveau de transfert? Y a-t-il un inconvénient majeur? Y a-t-il des fournisseurs à choisir ou à éviter spécifiquement?
la source
Réponses:
Tout d'abord, corrigez: assurez-vous que vous êtes sur la mise à jour cumulative 10 du Service Pack 1 2012 ou plus récent. Dans SQL 2014, Microsoft a modifié TempDB pour être moins désireux d'écrire sur le disque , et ils l'ont rétroporté de manière impressionnante vers 2012 SP1 CU10 , ce qui peut alléger une grande partie de la pression d'écriture TempDB.
Deuxièmement, obtenez des chiffres exacts sur votre latence. Vérifiez sys.dm_io_virtual_file_stats pour voir le blocage d'écriture moyen pour vos fichiers TempDB. Ma façon préférée de le faire est soit:
Regardez la section des statistiques des fichiers et concentrez-vous sur les écritures physiques. Les données SinceStartup peuvent être un peu trompeuses car elles incluent également les moments où CHECKDB est en cours d'exécution, et cela peut vraiment marteler votre TempDB.
Si votre latence d'écriture moyenne est supérieure à 3 ms, alors oui, vous pouvez avoir un stockage à semi-conducteurs dans votre SAN, mais ce n'est toujours pas rapide.
Considérez d'abord les SSD locaux pour TempDB. Les bons SSD locaux (comme les cartes PCIe NVMe d'Intel, qui coûtent moins de 2 000 USD en particulier aux tailles que vous décrivez) ont une latence extrêmement faible, inférieure à celle que vous pouvez obtenir avec le stockage partagé. Cependant, sous la virtualisation, cela présente un inconvénient: vous ne pouvez pas vMotion l'invité d'un hôte à un autre pour réagir au chargement ou aux problèmes matériels.
Considérez un lecteur RAM en dernier. Il y a deux gros problèmes avec cette approche:
Tout d'abord, si vous avez vraiment une activité d'écriture TempDB intense, le taux de changement sur la mémoire peut être si élevé que vous ne pourrez pas vMotion l'invité d'un hôte à un autre sans que tout le monde le remarque. Pendant vMotion, vous devez copier le contenu de la RAM d'un hôte à un autre. Si cela change vraiment aussi vite, plus vite que vous ne pouvez le copier sur votre réseau vMotion, vous pouvez rencontrer des problèmes (surtout si cette boîte est impliquée dans la mise en miroir, les AG ou un cluster de basculement.)
Deuxièmement, les lecteurs RAM sont des logiciels. Dans les tests de charge que j'ai effectués, je n'ai pas été très impressionné par leur vitesse sous une activité TempDB vraiment intense. S'il est si lourd qu'un SSD de niveau entreprise ne peut pas suivre, alors vous allez aussi taxer le logiciel du lecteur RAM. Vous voudrez vraiment charger ce test avant de commencer - essayez des choses comme beaucoup de reconstructions d'index simultanées sur différents index, toutes en utilisant sort-in-tempdb.
la source
La création d'un lecteur RAM devrait être triviale. De nombreuses clés USB et lecteurs optiques Linux amorçables créent un lecteur RAM et y stockent des fichiers OS. Le système de fichiers racine est alors en mémoire. Dans Windows, à l'époque, un lecteur RAM a été chargé en tant que pilote de périphérique dans config.sys. Habituellement, le pilote était chargé en mémoire élevée. À mon avis, c'est une solution très bonne et simple. Si vous avez créé votre solution à l'aide d'un lecteur RAM, j'aimerais en entendre parler. Je voudrais faire quelque chose de similaire mais je voudrais faire des écritures sur le stockage permanent et stocker une base de données dans la RAM. Dans mon cas, nous avons des machines qui peuvent installer plus de RAM que l'OS ne peut en utiliser. La création d'un disque RAM avant le chargement du système d'exploitation permettra d'utiliser la RAM que le système d'exploitation ne verrait pas autrement.
la source