La virtualisation est très populaire pour les organisations :elle leur permet de mieux utiliser le matériel en combinant plusieurs serveurs sur un seul hôte, fournit des capacités de haute disponibilité et permet de réduire divers coûts tels que le chauffage/refroidissement, les licences SQL Server et le matériel. J'ai participé à de nombreux projets avec des organisations pour les aider à migrer d'environnements physiques vers des environnements virtuels et je les ai aidées à profiter de ces avantages.
Ce que je veux partager avec vous dans cet article est un problème particulier que j'ai rencontré en travaillant avec Hyper-V sur Windows Server 2012 R2 à l'aide de la mémoire dynamique. Je dois admettre que la plupart de mes connaissances en virtualisation ont été avec VMware, mais cela change maintenant.
Lorsque vous travaillez avec SQL Server sur VMware, je recommande toujours de définir des réservations pour la mémoire. Ainsi, lorsque j'ai rencontré cette fonctionnalité de mémoire dynamique avec Hyper-V, j'ai dû faire des recherches. J'ai trouvé un article (Guide de configuration de la mémoire dynamique Hyper-V) qui explique de nombreux avantages et la configuration système requise pour l'utilisation de la mémoire dynamique. Cette fonctionnalité est plutôt cool dans la façon dont vous pouvez fournir plus ou moins de mémoire à une machine virtuelle sans qu'elle ait besoin d'être éteinte.
En jouant avec Hyper-V, j'ai trouvé que le provisionnement des machines virtuelles était simple et facile à apprendre. Avec peu d'efforts, j'ai pu créer un environnement de laboratoire pour simuler l'expérience de mon client. Le mérite revient à mon patron de m'avoir fourni un matériel formidable avec lequel travailler. J'utilise un Dell M6800 avec un processeur i7, 32 Go de RAM et deux SSD de 1 To. Cette bête est meilleure que beaucoup de serveurs sur lesquels j'ai travaillé.
En utilisant VMware Workstation 11 sur mon ordinateur portable, j'ai créé un invité Windows Server 2012 R2 avec 4 vCPU, 24 Go de RAM et 100 Go de stockage. Une fois l'invité créé et corrigé, j'ai ajouté le rôle Hyper-V et provisionné un invité sous Hyper-V. Le nouvel invité a été construit avec Windows Server 2012 R2 avec 2 vCPU, 22 Go de RAM et 60 Go de stockage exécutant SQL Server 2014 RTM.
J'ai exécuté trois séries de tests, chacun utilisant la mémoire dynamique. Pour chaque test, j'ai utilisé le générateur de données SQL de Red Gate par rapport à la base de données AdventureWorks2014 pour remplir le pool de mémoire tampon. Pour le premier test, j'ai commencé avec 512 Mo pour la valeur de la RAM de démarrage, car il s'agit de la quantité minimale de mémoire pour démarrer Windows Server 2012 R2 et le pool de mémoire tampon a cessé d'augmenter à environ 8 Go.
Pour chaque test, je tronquais ma table de test, arrêtais l'invité, modifiais les paramètres de mémoire et redémarrais l'invité. Pour le deuxième test, j'ai augmenté la RAM de démarrage à 768 Mo et le pool de mémoire tampon n'a augmenté qu'à un peu plus de 12 Go.
Pour le troisième et dernier test, la RAM de démarrage a été augmentée à 1 024 Mo, le générateur de données a été exécuté et le pool de mémoire tampon a pu augmenter jusqu'à un peu moins de 16 Go.
Faire un peu de calcul sur ces valeurs montre que le pool de mémoire tampon ne peut pas augmenter de plus de 16 fois la RAM de démarrage. Cela peut être très problématique pour SQL Server si la RAM de démarrage est inférieure à 1/16 de la taille de la mémoire maximale. Imaginons un invité Hyper-V avec 64 Go de RAM exécutant SQL Server avec une valeur de RAM de démarrage de 1 Go. Nous avons observé que le pool de mémoire tampon ne serait pas en mesure d'utiliser plus de 16 Go avec cette configuration, mais si nous définissons la valeur de la RAM de démarrage sur 4096 Mo, le pool de mémoire tampon pourrait augmenter de 16 fois, ce qui nous permettrait d'utiliser tous les 64 Go.
Les seules références que j'ai pu trouver sur la raison pour laquelle le pool de mémoire tampon est limité à 16 fois la valeur de la RAM de démarrage se trouvaient aux pages 8 et 16 du livre blanc, Meilleures pratiques pour l'exécution de SQL Server avec HVDM. Ce document explique que puisque la valeur du cache de tampon est calculée au démarrage, il s'agit d'une valeur statique et n'augmente pas. Toutefois, si SQL Server détecte que l'ajout de mémoire à chaud est pris en charge, il augmente la taille réservée à l'espace d'adressage virtuel pour le pool de mémoire tampon de 16 fois la mémoire de démarrage. Ce document indique également que ce comportement affecte SQL Server 2008 R2 et versions antérieures, mais mon test a été effectué sur Windows Server 2012 R2 avec SQL Server 2014. Je contacterai donc Microsoft pour mettre à jour le document des meilleures pratiques.
Étant donné que la plupart des administrateurs de base de données de production ne provisionnent pas de machines virtuelles ou ne travaillent pas beaucoup dans cet espace, et que les ingénieurs en virtualisation n'étudient pas la technologie SQL Server la plus récente et la plus performante, je peux comprendre que ces informations importantes sur la façon dont le pool de mémoire tampon gère la mémoire dynamique sont inconnues de beaucoup. de personnes.
Même suivre les articles peut être trompeur. Dans l'article Guide de configuration de la mémoire dynamique Hyper-V, la description de la RAM de démarrage indique :
Spécifie la quantité de mémoire requise pour démarrer la machine virtuelle. La valeur doit être suffisamment élevée pour permettre au système d'exploitation invité de démarrer, mais doit être aussi faible que possible pour permettre une utilisation optimale de la mémoire et des taux de consolidation potentiellement élevés.Utilisation optimale de la mémoire pour qui, l'hôte ou l'invité ? Si un administrateur de virtualisation lisait ceci, il déterminerait probablement que cela signifie la mémoire minimale autorisée pour démarrer le système d'exploitation.
Être responsable de SQL Server signifie que nous devons connaître les autres technologies qui peuvent influencer notre environnement. Avec l'introduction des SAN et de la virtualisation, nous devons comprendre pleinement comment les éléments de ces environnements peuvent avoir un impact négatif sur SQL Server et, plus important encore, comment communiquer efficacement les préoccupations aux personnes responsables de ces systèmes. Un administrateur de base de données n'a pas nécessairement besoin de savoir comment provisionner le stockage dans un SAN ou comment provisionner ou être capable d'administrer un environnement VMWare ou Hyper-V, mais il doit connaître les bases du fonctionnement des choses.
En connaissant les bases du fonctionnement d'un SAN avec les baies de stockage, les réseaux de stockage, les chemins multiples, etc., ainsi que la manière dont l'hyperviseur fonctionne avec la planification des processeurs et l'allocation de stockage dans la virtualisation, un administrateur de base de données peut mieux communiquer et résoudre les problèmes en cas de problème. . Au fil des ans, j'ai travaillé avec succès avec un certain nombre d'administrateurs de SAN et de virtualisation pour créer des normes pour SQL Server. Ces normes sont propres à SQL Server et ne s'appliquent pas nécessairement aux serveurs Web ou d'applications.
Les administrateurs de base de données ne peuvent pas vraiment compter sur les administrateurs de SAN et de virtualisation pour comprendre pleinement les meilleures pratiques pour SQL Server, même si cela serait agréable, nous devons donc nous renseigner du mieux que nous pouvons sur la façon dont leurs domaines d'expertise peuvent nous impacter.
Au cours de mes tests, j'ai utilisé une requête du billet de blog de Paul Randal, Problèmes de performances liés à la mémoire du pool de mémoire tampon gaspillée, pour déterminer la quantité de pool de mémoire tampon utilisée par la base de données AdventureWorks2014. J'ai inclus le code ci-dessous :
SELECT
(CASE WHEN ([database_id] = 32767)
THEN N'Resource Database'
ELSE DB_NAME ([database_id]) END) AS [DatabaseName],
COUNT (*) * 8 / 1024 AS [MBUsed],
SUM (CAST ([free_space_in_bytes] AS BIGINT)) / (1024 * 1024) AS [MBEmpty]
FROM sys.dm_os_buffer_descriptors
GROUP BY [database_id]; Ce code est également idéal pour dépanner laquelle de vos bases de données consomme la majorité de votre pool de mémoire tampon afin que vous puissiez savoir sur quelle base de données vous devez vous concentrer sur le réglage des requêtes à coût élevé. Si vous êtes une boutique Hyper-V, vérifiez auprès de votre administrateur si la mémoire dynamique peut être configurée de manière à avoir un impact négatif sur votre serveur.
