SQL Server 2008 R2 (10.50.1600) est exécuté sur un serveur virtuel Windows 2008 R2. Après la mise à niveau du processeur de 1 cœur à 4 ordinateurs et de la RAM de 4 Go à 10 Go, nous avons constaté une baisse des performances.
Quelques observations que je vois:
- Une requête dont l’exécution a pris <5 secondes prend maintenant> 200 secondes.
- Le processeur est indexé à 100 avec sqlservr.exe comme coupable.
- Un compte sélectionné (*) sur une table comportant 4,6 millions de lignes a duré plus de 90 secondes.
- Les processus en cours d'exécution sur le serveur n'ont pas changé. Le seul changement a été d'augmenter le nombre de processeurs et de béliers.
- Les autres serveurs SQL ont un fichier de pagination statique dans lequel ce serveur est configuré pour le gérer seul.
Quelqu'un at-il déjà rencontré ce problème?
Par sp_BlitzErik, j'ai couru
EXEC dbo.sp_BlitzFirst @SinceStartup = 1;
En me donnant ces résultats.
Réponses:
Il se passe beaucoup de choses ici, et la plupart sont assez larges et vagues.
La version 2008R2 RTM est sortie le 21 avril 2010. Elle n’est plus supportée. Vous aurez pour priorité de vous procurer le dernier Service Pack, qui est sorti il y a à peu près 3 ans aujourd'hui. De cette façon, vous serez couvert si vous rencontrez un bug étrange ou quelque chose. Rendez-vous ici pour savoir ce que vous devez télécharger.
Comme vous avez ajouté des vCPU (de 1 à 4) et n'avez modifié aucun paramètre, vos requêtes peuvent maintenant être parallèles. Je sais que cela sonne comme si tout allait être plus rapide, mais accrochez-vous!
Vous avez peut-être ajouté de la RAM, mais vous n’avez peut-être pas modifié la mémoire maximale du serveur pour que votre serveur puisse en tirer parti.
Déterminez ce que votre serveur attend. Un projet open source sur lequel je travaille fournit des scripts gratuits pour vous aider à mesurer votre serveur SQL. Rendez -vous ici si vous voulez essayer.
Vous voudrez utiliser sp_BlitzFirst pour consulter les statistiques d'attente de votre serveur. Vous pouvez l'exécuter de plusieurs manières.
Cela vous montrera ce que votre serveur attend depuis son démarrage.
EXEC dbo.sp_BlitzFirst @SinceStartup = 1;
Cela vous montrera quelles requêtes attendent maintenant, pendant une fenêtre de 30 secondes.
EXEC dbo.sp_BlitzFirst @Seconds = 30, @ExpertMode = 1;
Une fois que vous avez déterminé quelles demandes sont en attente (il y a une tonne d'articles sur les statistiques d'attente), vous pouvez commencer à apporter des modifications pour que tout soit sous contrôle.
Si vous les voyez attendre
CXPACKET
, cela signifie que vos requêtes vont en parallèle, et peut-être se piétinent. Si vous cliquez là-dessus, vous voudrez probablement envisager d’augmenter le seuil de coût pour le parallélisme jusqu’à 50, et peut-être de ramener MAXDOP à 2.Après cette étape, vous souhaitez utiliser quelque chose comme sp_WhoIsActive ou sp_BlitzWho (ce dernier est déjà dans le référentiel GitHub) pour commencer à capturer les plans de requête. Mis à part les statistiques d'attente, il s'agit de l'une des choses les plus importantes à considérer pour comprendre ce qui ne va pas.
Vous pouvez également consulter cet article de Jonathan Kehayias sur les compteurs VMWare à consulter en relation avec SQL Server.
Mise à jour
Revoir les statistiques d'attente et le garçon sont-ils étranges. Il y a définitivement quelque chose avec les processeurs. Votre serveur est généralement ennuyé, mais quand les choses se réchauffent, les choses se détériorent. Je vais essayer de décomposer cela facilement.
Vous frappez une attente empoisonnée appelée
THREADPOOL
. Vous n'en avez pas une tonne, mais c'est logique car votre serveur n'est pas très actif. Je vais expliquer pourquoi dans une minute.Vous avez des attentes moyennes très longues
SOS_SCHEDULER_YIELD
etCXPACKET
. Vous êtes sur une machine virtuelle, vous devez donc vous assurer que SQL Server a des réservations ou que la boîte n'est pas terriblement sursouscrite. Un voisin bruyant peut vraiment gâcher votre journée ici. Vous allez également vouloir vous assurer que le serveur / l'invité VM / l'hôte VM ne s'exécutent pas en mode d'alimentation équilibrée. Cela permet à vos processeurs de ralentir inutilement, sans retour immédiat à la vitesse maximale.Comment sont-ils liés? Avec 4 processeurs, vous avez 512 threads de travail. N'oubliez pas que vous aviez le même montant avec un seul processeur, mais maintenant que vos requêtes peuvent aller en parallèle, elles peuvent consommer beaucoup plus de threads de travail. Dans votre cas, 4 threads par branche parallèle d'une requête parallèle.
Qu'est-ce qui se passe en parallèle? Très probablement tout. Le seuil de coût par défaut pour le parallélisme est 5. Ce nombre a été défini par défaut à la fin des années 90 sur un poste de travail de ce type .
Certes, votre matériel est plus petit que la plupart des ordinateurs portables, mais vous êtes encore un peu en avance sur cette chose.
Lorsque de nombreuses requêtes parallèles sont lancées, vous manquez de ces threads de travail. Lorsque cela se produit, les requêtes restent en attente des threads. C’est également là que les
SOS_SCHEDULER_YIELD
choses entrent en jeu. Les requêtes quittent les processeurs et ne s’allument pas pendant longtemps. Je ne vois aucune attente bloquante, alors vous êtes probablement tous coincés dans les attentes de parallélisme intra-requête.Que pouvez-vous faire?
sp_BlitzIndex
pour rechercher les demandes d'index manquantes.Pour un dépannage plus approfondi, consultez le livre blanc que j'ai écrit pour Google sur le dimensionnement du matériel dans le cloud.
J'espère que cela t'aides!
la source
Oui! J'ai rencontré ce type de situation sur vms SQL Server dans notre batterie de serveurs. Examinez le temps de préparation du processeur hôte de la machine virtuelle et les compteurs du pilote de ballon de mémoire. CPU READY TIME - PARTIE I DU BLOGUE et comprendre la montée en ballon de VMware Travailler avec mon administrateur système était essentiel, mais n'était pas facile ...
la source
Une chose que je n'ai pas vue souligner est que l'ajout de vCPU à une machine virtuelle peut très souvent la ralentir en raison de la planification.
L'idée de base est que si une machine virtuelle a 4 vCPU, l'hyperviseur doit attendre que 4 cœurs physiques soient disponibles pour pouvoir planifier toutes les vCPU, même si 3 d'entre eux sont inactifs.
Si votre hôte ne contient pas beaucoup de cœurs et que vos autres charges de travail sont occupées, cela peut entraîner une attente supplémentaire et une baisse significative des performances.
Dans VMware ESXi, vous pouvez le voir dans les graphiques avancés via CPU Ready.
Voici l'un des nombreux articles avec un exemple concret de ce qui se passe et comment cela a été diagnostiqué .
L'ajout de RAM supplémentaire peut également entraîner une baisse soudaine des performances si l'allocation de RAM de la machine virtuelle est supérieure à un nœud NUMA.
De plus, la configuration de vos vCPU (vSockets contre vCores) peut en réalité affecter certaines applications telles que SQL Server. Cela est dû au fait que le serveur SQL est lui-même conscient de NUMA (pour éviter le même type de perte de performances de NUMA-spanning) et parce que VMware peut présenter les nœuds NUMA virtuels différemment.
Ceci est couvert dans un article de blog sur le propre site de VMware .
Cela étant dit, je suis heureux que vous ayez résolu les problèmes avec l'aide d'Erik, mais vous voudrez peut-être également examiner et prendre en compte ces éléments.
la source
Juste une petite aide (je ne peux pas poster ceci en tant que commentaire), en continuant la réponse de @ sp_BlitzErik, Pinal et Max Vernon (je ne me souviens plus où) utiliseraient des requêtes spécifiant la quantité maximale de MAXDOP à utiliser:
-------------------------------------------------- -------
la source
MAXDOP = 2
qui est juste en ligne avec @sp_BlitzErik. Merci!