Construire le serveur de production Microsoft SQL Server 2012 idéal peut être une tâche ardue, avec des variables telles que le stockage, la RAM ou la sélection de processeurs, même les administrateurs informatiques chevronnés. Nous avons publié pour la dernière fois une analyse sur la sélection des meilleurs 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 élément clé lorsque l'on considère les besoins de performances de SQL exécuté sur du fer. Pour ce test, nous avons utilisé le même banc d'essai que l'étude du processeur Intel, cette fois en nous concentrant sur l'augmentation de la RAM Micron PC3-12800 avec le processeur et le stockage les plus performants pour évaluer son impact sur les performances.
Construire le serveur de production Microsoft SQL Server 2012 idéal peut être une tâche ardue, avec des variables telles que le stockage, la RAM ou la sélection de processeurs, même les administrateurs informatiques chevronnés. Nous avons publié pour la dernière fois une analyse sur la sélection des meilleurs 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 élément clé lorsque l'on considère les besoins de performances de SQL exécuté sur du fer. Pour ce test, nous avons utilisé le même banc d'essai que l'étude du processeur Intel, cette fois en nous concentrant sur l'augmentation de la RAM Micron PC3-12800 avec le processeur et le stockage les plus performants pour évaluer son 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 dans un Supermicro SuperStorage Server 2027R-AR24NV exécutant Windows Server 2012, qui est un boîtier à double socket 2U prenant en charge les familles de processeurs Intel E5-2600 et E5-2600 v2. La RAM système est composée de seize Modules DIMM Micron PC16-3 de 12800 Go qui restent statiques pour chaque test. Pour modifier la quantité de RAM utilisée par SQL Server, nous modifions le paramètre d'allocation, en le limitant à une quantité sélectionnée pour chaque étape. Nous avons exploité les 2.6 To Fusion ioMemory PX600 pour le stockage sur l'hôte, qui a affiché de très bons chiffres de latence SQL Server (le produit de génération actuelle le plus rapide que notre laboratoire a testé).
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
Performance
Chaque intervalle de pas de RAM spécifié a été testé de la même manière : en tirant parti de notre Référence OLTP SQL Server 2012 avec la base de données située sur le PX600 à l'intérieur du serveur Supermicro 2P à nœud unique. Comme avec la plupart des périphériques de stockage de la même classe, nous ne nous soucions pas tellement des transactions par seconde ; l'accent est vraiment mis sur la latence pour que chacune de ces transactions se termine.
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
