Vitesse d'horloge du processeur par rapport au nombre de cœurs du processeur - GHz supérieur ou plusieurs cœurs pour SQL Server?
Nous commençons à provisionner un ensemble de serveurs physiques pour un cluster virtuel de nœuds SQL Server 2016 dans VMware. Nous utiliserons des licences Enterprise Edition.
Nous prévoyons de configurer 6 nœuds, mais il y a un petit débat sur la façon idéale de provisionner les serveurs physiques en ce qui concerne la vitesse d'horloge du processeur par rapport au nombre de cœurs du processeur.
Je sais que cela dépend en grande partie du volume de transactions et du nombre de bases de données stockées parmi d'autres facteurs spécifiques au logiciel, mais existe-t-il une règle générale qui est conseillée?
Par exemple, un serveur physique double 8 cœurs, 3,2 GHz (16 cœurs) est-il plus préférentiel qu'un serveur double 16 cœurs, 2,6 GHz (32 cœurs)?
Quelqu'un est-il tombé sur un livre blanc qui approfondit ce type de sujet?
La règle générale est de maintenir le nombre de cœurs aussi bas que possible et la vitesse du processeur aussi élevée que possible. Les calculs de licence à ce sujet prouvent le point à environ 7500 USD par cœur pour l'édition coûteuse.
L'achat du matériel approprié peut être rentable en réduisant les coûts de licence. Voir Sélection du processeur pour SQL Server par Glenn Berry. C'est une excellente ressource sur la façon de choisir un processeur pour SQL Server.
Une fois que vous prenez en compte la structure de licence par cœur de SQL Server, il est logique de toujours utiliser la vitesse de processeur la plus rapide disponible, quel que soit le type de charge de travail, que ce soit OLTP ou analytique. Avoir le cœur le plus rapide possible la vitesse ne sera jamais un problème. Augmentez le nombre de cœurs au besoin, mais ne le faites jamais en réduisant la vitesse du cœur.
En d'autres termes, ne pensez pas que les processeurs 16 x 2,2 GHz sont identiques aux processeurs 8 x 4,5 GHz. Les économies de coûts liées à l'utilisation des processeurs 2,2 GHz par rapport aux processeurs 4,5 GHz sont susceptibles d'être d'un maximum d'environ 10 000 USD (pour une machine à deux processeurs basée sur Xeon). Passer de 8 cœurs à 16 cœurs avec SQL Server Enterprise Edition coûtera probablement plus de 60 000 USD en frais de licence. En d'autres termes, vous pourriez économiser 10 000 $ en coûts de matériel, mais vous perdrez 50 000 $ supplémentaires en licences.
Si vous décidez que vous avez besoin de beaucoup de muscle de traitement parallèle, et décidez que vous avez besoin de 32 cœurs pour la tâche à accomplir, opter pour les cœurs les plus rapides rapportera un temps de traitement réduit. Personne ne vous en voudra.
Cela dit, si le choix est un CPU ou plus d'un CPU, toujours aller avec plus d'un . L'exécution de SQL Server (ou de tout SGBD) sur un seul processeur peut provoquer toutes sortes de problèmes car la capacité des opérations simultanées est très limitée.
Hold on hold on hold on
Bien que les performances et les licences soient intéressantes, elles ne sont pas le seul aspect d'une charge de travail à prendre en compte.
Les threads de travail peuvent avoir un impact sur le choix du processeur.
Threads de travail?
Ouais mec! Ce sont les choses que votre serveur SQL utilisera pour exécuter vos requêtes et effectuer toutes les tâches d'arrière-plan nécessaires pour garder les choses en forme.
Lorsque vous manquez de threads de travail, vous appuyez sur THREADPOOL attend
THREADPOOL?
THREADPOOL. C'est l'une des attentes les plus désagréables que vous puissiez avoir sur votre serveur, avec RESOURCE_SEMAPHORE et RESOURCE_SEMAPHORE_QUERY_COMPILE . Mais ce sont des attentes de mémoire, et c'est une question de CPU.
Revenons donc à la raison pour laquelle il s'agit de wiggity wack.
C'est ainsi que SQL Server calcule les threads de travail :
Remarquez que le fait de doubler le nombre de cœurs ne double pas le nombre maximal de threads de travail, et vous obtenez le même nombre avec 1 cœur que vous le faites avec 4 cœurs? L'équation est: 512 + ((logical CPUs - 4) * 16)
C'est dommage, car lorsque le nombre de cœurs augmente, la vitesse d'horloge chute généralement d'une génération ou deux en arrière.
Jetez un oeil à n'importe quel ligne récente de puces Intel montrera une tendance similaire.
Comment savoir de combien de threads j'ai besoin?
Cela dépendra beaucoup de:
- Nombre d'utilisateurs
- Nombre de requêtes parallèles
- Nombre de requêtes en série
- Nombre de bases de données et synchronisation des données (mise en miroir, AG, sauvegardes pour l'envoi de journaux)
- Si vous laissez MAXDOP et CTFP aux valeurs par défaut
Si vous n'en manquez pas aujourd'hui, vous êtes probablement d'accord.
Mais comment savoir si vous l'êtes?
Il y a de bonnes questions, et il y a de grandes questions, et laissez-moi vous dire quelque chose, c'est une GRANDE QUESTION.
THREADPOOL peut se manifester sous la forme problèmes de connexion , et vous pouvez voir des messages dans le journal des erreurs indiquant que vous ne pouvez pas générer un thread .
Vous pouvez également consulter les statistiques d'attente de votre serveur en utilisant un outil gratuit comme sp_Blitz ou sp_BlitzFirst (divulgation complète, je contribue à ce projet).
EXEC sp_Blitz
EXEC sp_BlitzFirst @SinceStartup = 1
Puis-je simplement augmenter le nombre maximal de threads de travail?
L'augmentation du MWT peut entraîner une augmentation de SOS_SCHEDULER_YIELD attend.
Ce n'est pas la fin du monde, mais pensez-y comme l'ajout d'un buncha hurlant des enfants à la classe d'un professeur.
Tout d'un coup, il sera plus difficile pour chaque enfant d'attirer l'attention.
Lorsqu'un processus épuise son quantum de 4 ms , il y aura potentiellement plus de threads devant lui en attente de monter sur le CPU.
Les performances peuvent sembler à peu près les mêmes.
Comment puis-je utiliser moins de threads de travail?
Vous [cruel] cruel d'un [substantif], ce sont des travailleurs avec des familles à soutenir! Hypothèques! Rêves!
Mais d'accord, je dois respecter les résultats. Tu es le patron.
L'endroit le plus simple pour commencer est de modifier les paramètres comme MAXDOP et Cost Threshold For Parallelism par défaut.
Si vous avez des questions sur la façon de les configurer, rendez-vous ici:
Après cela, votre travail devient beaucoup plus difficile. Vous devez comprendre ce qui utilise tous ces fils. Vous pouvez parfois le faire en consultant vos statistiques d'attente.
Plus précisément, si vous avez des attentes élevées sur le parallélisme (CXPACKET) ET des attentes élevées sur les verrous (LCK_), vous risquez de rencontrer de longues chaînes de blocage impliquant des requêtes parallèles.
Tu sais ce qui pue? Pendant que toutes ces requêtes parallèles attendent d'obtenir leurs verrous, elles ne rendent pas leurs threads alloués.
Vous pouvez presque entendre que quatre cœurs VM que votre administrateur a assuré que vous étiez plus que suffisant pour toute charge de travail à bout de souffle, hein?
Malheureusement, le type de requête et de réglage d'index que vous devez faire pour résoudre ce problème dépasse le cadre de la question.
J'espère que cela t'aides!
Le long et le court de celui-ci est: La plupart des charges de travail pour SQL Server sont OLTP qui bénéficie de vitesses d'horloge plus élevées car il s'agit d'une opération série.
À moins que vous ne conceviez spécifiquement un système massivement parallèle, les vitesses d'horloge seront toujours gagnantes. Les cas de bord existent mais c'est la réponse à 95% du temps. Le fait que cela coûte moins cher est également une bonne chose.