Configurer un serveur de production Microsoft SQL Server 2012 idéal peut s'avérer complexe, le choix du stockage, de la RAM ou du processeur pouvant déconcerter même les administrateurs informatiques les plus expérimentés. Notre dernier article présentait une analyse du choix du meilleur processeur Intel Xeon E5-2600 v2 pour exécuter SQL Server 2012 dans des environnements non virtualisés. Outre le processeur, la RAM est un autre composant essentiel pour optimiser les performances de SQL Server sur un serveur physique. Pour ces tests, nous avons utilisé la même configuration que pour l'étude sur les processeurs Intel, en nous concentrant cette fois sur l'association de la RAM Micron PC3-12800 avec le processeur et le stockage les plus performants afin d'évaluer leur impact sur les performances.
Traditionnellement, plus de RAM pour SQL Server offre de meilleures performances. L'utilisation de RAM supplémentaire réduit l'encombrement des E/S sur une baie de stockage donnée et offre également certains avantages en matière de mise en cache. Tout étant égal, nous examinons la quantité de RAM que vous pouvez consacrer à SQL Server tout en conservant un profil de faible latence. Dans cet article, nous montrons l'impact sur les performances de l'allocation de 128 Go dédiés à SQL Server, où nous testons actuellement les appareils pour les évaluations d'entreprise, jusqu'à 8 Go.
Banc d'essai
Pour cette analyse, nous évaluons la mémoire Micron PC3-12800 DDR3 au sein d'un serveur Supermicro SuperStorage Server 2027R-AR24NV exécutant Windows Server 2012. Ce serveur 2U biprocesseur prend en charge les processeurs Intel E5-2600 et E5-2600 v2. La mémoire vive du système est composée de seize modules DIMM Micron PC3-12800 de 16 Go, dont la configuration reste inchangée pour chaque test. Afin de modifier la quantité de mémoire vive utilisée par SQL Server, nous ajustons le paramètre d'allocation, en la limitant à une valeur définie pour chaque étape. Nous avons utilisé le disque dur Fusion ioMemory PX600 de 2.6 To comme stockage interne. Ce dernier a affiché d'excellents résultats en termes de latence SQL Server (il s'agit du produit de dernière génération le plus rapide testé par notre laboratoire).
Configuration du serveur
- 2 processeurs Intel Xeon E5-2687W v2 - 25 Mo de cache, 3.40 GHz, 8 cœurs
- Jeu de puces Intel C602
- Mémoire – 256 Go (16 x 16 Go) RDIMM enregistrés Micron DDR1600 à 3 128 MHz (8 Go dédiés au système, 128 à XNUMX Go dédiés à SQL)
- Windows Server standard 2012
- 3 HBA Supermicro SAS3 (contrôleurs LSI SAS 3008)
- SSD de démarrage Micron P200m de 400 Go
- 1 x adaptateur Mellanox ConnectX-3 double port VPI PCIe 3.0 (tissu InfiniBand LoadGen)
- 1 adaptateur Emulex OCe11102 double port 10 GbE
Configuration du stockage
- SanDisk Fusion ioMemory PX600 2.6 To
- 80 % de surprovisionnement en mode hautes performances
- Puissance totale activée
- Micrologiciel/Pilotes VSL 4.1.1
Performances
Chaque intervalle de réglage de la RAM a été testé de la même manière : en utilisant notre benchmark OLTP SQL Server 2012 avec la base de données hébergée sur le PX600 au sein du serveur Supermicro 2P à nœud unique. Comme pour la plupart des périphériques de stockage de cette catégorie, le nombre de transactions par seconde n'est pas notre principal critère ; l'accent est mis sur la latence d'exécution de chaque transaction.
Comme prévu, de plus grandes quantités de RAM allouées au serveur SQL ont généré des performances transactionnelles plus élevées. Entre 128 Go et 64 Go, nous n'avons pas vu de changement énorme dans le TPS. En fait, la chute entre 96 Go et 64 Go est restée à peu près dans la même marge d'erreur. La différence de 16 Go à 8 Go a apporté le changement le plus important, ce qui nous indique que 16 Go est probablement le seuil minimum utile pour cette configuration de test et de serveur particulière.
En nous concentrant sur la latence, nous voyons à quel point le Fusion ioMemory PX600 a maintenu ses performances à faible latence avec les résultats de 128 Go, 96 Go et 64 Go entre 2 et 3 ms. La baisse à 32 Go a augmenté la latence d'environ 66%, mais la baisse suivante des 16 Go a été beaucoup plus dramatique. Ce changement a augmenté la latence de 200 %, qui a ensuite augmenté de 153 % lorsque la RAM a été réduite à 8 Go.
Bien que l'impact sur le stockage n'ait pas été démontré dans le cadre de ce test, chaque augmentation de l'allocation DRAM a considérablement réduit la charge perçue par le périphérique de stockage sur lequel la base de données résidait. En bref, plus de mémoire se traduit par moins de requêtes atteignant le stockage, au lieu de rester dans la mémoire système. Alors que 128 Go de RAM avaient une charge en arrière-plan de 50 à 100 Mo/s, 16 Go sont passés à 800 Mo/s (pas pendant l'activité d'écriture de journal qui peut provoquer des pics importants pour toute configuration DRAM). Avec un support de stockage moindre, ces résultats seraient encore plus élevés.
Conclusion
Lors de la création d'un serveur SQL non virtualisé hautes performances, de nombreuses considérations doivent être prises en compte. Dans le premier article, nous avons examiné le processeur et son impact sur les performances SQL. Ici, nous utilisons le stockage et les processeurs les plus performants de l'hôte pour tester la RAM. En partenariat avec Micron, nous avons effectué les mêmes tests, allant de 8 Go à 128 Go de RAM dédiée à SQL. Les résultats sont assez intuitifs, avec généralement plus de RAM étant mieux en termes de latence. Il y a cependant un point de rupture où la latence voit un pic dramatique dans cette configuration. À 16 Go, la latence augmente de 3 fois par rapport à 32 Go et à 8 Go, l'impact est encore plus grave. Pour des performances optimales, 128 Go de RAM pour SQL avec des processeurs à la vitesse d'horloge maximale et un stockage PCIe de pointe génèrent une latence de seulement 2 ms.
Sélection du meilleur processeur Intel Xeon E5-2600 v2 pour SQL Server 2012
Amazon