Parlant d'une expérience qui est humble mais je pense qu'il vaut la peine d'être partagé, le principal goulot d'étranglement avec les bases de données SQL (Sybase et SQL Server ici) est le stockage.
Mais je pense qu'il est juste que quelqu'un compare d'abord sa configuration avant de faire de fausses hypothèses. Dans mon cas, l'utilisation du processeur n'a jamais augmenté suffisamment pour justifier la mise à niveau du processeur de si tôt. Au lieu de cela, j'ai mis à niveau un seul disque vers RAID 1, puis vers RAID 10 + une bosse de 8 Go à 16 Go de RAM.
Toutes ces mises à niveau RAID ont contribué à réduire les temps d'attente précédents d'un facteur de 2 à 6. Je soupçonne que la mise à niveau vers des SSD serait encore meilleure. Si vous y réfléchissez, tout peut être réduit à une bande passante (théorique). Votre combo [(RAM Speed + RAM Size + Memory controller) link to CPU] a une limite de bande passante qui serait le facteur le plus important dans les opérations de lecture lorsque vos données doivent toujours être mises en cache, votre stockage (RAID) particulier a une limite de bande passante ( affecte les lectures lorsque le cache est manquant et écrit lors du vidage ou lorsque de nombreux clients écrivent beaucoup de données combinées).
Normalisez toutes ces limites autant que possible (rapprochez-les de sorte que vous n'avez pas de ressources gaspillées) et augmentez-les autant que possible (mettez à niveau si nécessaire et uniquement si nécessaire, ne laissez pas les ressources devenir gaspillées si le système gagne). t être en mesure de les utiliser car un autre goulot d'étranglement est en cours). En fin de compte, votre pire goulot d'étranglement sera le sous-système de serveur le moins performant (avec le moins de bande passante) dans votre configuration particulière.
Je pourrais également ajouter que, dans le processus de mise à niveau, j'ai créé des configurations RAID distinctes pour les fichiers de base de données et les fichiers journaux de base de données. La raison en était que les fichiers journaux de la base de données ont tendance à être gourmands en écriture. Un fichier journal est utilisé pour récupérer une base de données à partir d'un plantage et il est toujours écrit immédiatement dès qu'une transaction est validée avant que des données ne soient écrites dans le fichier de base de données.
Un fichier journal est également utilisé par certains serveurs de réplication de base de données, mais la plupart de la réplication n'est pas effectuée instantanément mais fréquemment, de sorte que l'impact sur les performances de lecture est minime ici. Au moins je le pense. J'ai effectué une analyse comparative minimale lors de cette mise à niveau.Je recommande donc à quiconque de comparer d'abord ses différentes configurations et de mettre à niveau son stockage, puis la RAM et la liaison réseau, avant de penser à mettre à niveau leurs processeurs.
Après des mises à niveau plus poussées sur plus de 5 serveurs, je suis revenu pour partager mon expérience. Je plaide définitivement pour la première mise à niveau du stockage, puis de la RAM, puis du CPU. La raison en est la disparité des bandes passantes dans le système entre le stockage, la RAM et le CPU, par ordre croissant. J'ai donc mis à niveau un tas de serveurs de RAID10 et de doubles RAID1 vers SSD.
La façon dont je l'ai fait en raison de problèmes de coût (j'ai 20 serveurs de plus à mettre à niveau) consiste à déplacer les fichiers de données et d'objets de la base de données vers un SSD (oui, un seul SSD en RAID0) et de déplacer le journal des transactions plus tempdb vers un 4xHDD RAID10 configuration. J'ai également testé avec le tempdb sur le SSD avec d'excellents résultats (en fait de très bons résultats avec des requêtes plus de 15 fois plus rapides parfois, produisant des rapports prenant quelques secondes au lieu de minutes dans le passé) mais j'ai ensuite déplacé le tempdb vers le disque RAID10 parce que des problèmes d'usure en écriture intensifs pour le SSD.
Alors maintenant, fondamentalement, j'ai observé des temps de réponse 10 à 15 fois plus rapides pour certaines des requêtes les plus longues. Le SSD est idéal pour lire rapidement des données dans la RAM car SQL Server n'apporte pas de données dans la RAM jusqu'à ce que cela soit demandé et bien sûr les données doivent d'abord être chargées dans la RAM pour être traitées par le CPU (plus tard, dans le cache L1, L2, L3) , de sorte que les SSD contribuent à réduire considérablement ce temps d'attente initial. Et les disques SSD aident également à réduire les temps de permutation ... en effaçant la RAM et en chargeant de nouvelles données, surtout si votre base de données est plus grande que ce qui peut tenir dans la RAM.
Dans l'ensemble, nous sommes très heureux et fonctionnons ainsi depuis plusieurs mois dans une sorte de processus de migration lente pour permettre aux serveurs de fonctionner afin que je puisse collecter des informations sur le niveau d'usure avant de basculer tous mes serveurs dans cette configuration. Et ce n'est que SQL Server Express! : D - Assurez-vous simplement que vos SSD peuvent fournir des IOPS constants car c'est une autre chose qui fait une énorme différence (il suffit de google). C'est pourquoi j'ai choisi les SSD de la série Intel DC (DataCenter).