Dans cet article, je vais discuter d'une méthodologie générale pour résoudre les problèmes de performances du processeur. J'aime appliquer des méthodologies par défaut et j'aime aussi gagner en efficacité dans la façon dont je résous les problèmes en fonction des expériences passées. Sans cadre général, il devient trop facile de passer à côté de la véritable cause profonde au milieu d'une crise.
Les étapes que je vais décrire dans cet article sont les suivantes :
- Définir le problème
- Valider les conditions actuelles
- Répondez "Est-ce SQL Server" ?
- Identifier les consommateurs de CPU
- Faites correspondre le modèle et résolvez
Cet article couvrira chacune de ces étapes. Je suppose que vous n'utilisez peut-être pas un outil de surveillance tiers. Si tel est le cas, le cadre ici s'applique toujours, mais vos sources de données et vos outils à votre disposition différeront de ce que je décris.
Définir le problème
Nous devons d'abord cerner le problème. Lorsque quelqu'un vient vers vous et dit qu'il voit un problème de performances du processeur, cela peut signifier un certain nombre de choses différentes. La première tâche consiste donc à comprendre quelle est la nature actuelle du problème de performances du processeur.
Certaines catégories courantes incluent :
- La disponibilité est affectée en raison des "processeurs indexés". Par exemple, tous les planificateurs fonctionnent à 100 % à tous les niveaux et le débit est bloqué ou considérablement réduit.
- Dégradation des performances due à une utilisation du processeur "plus élevée que la normale". Nous ne sommes donc pas ancrés, mais vos processeurs fonctionnent à un pourcentage plus élevé que d'habitude et cela a probablement un impact sur les performances.
- Une autre catégorie courante de problème de performances du processeur est le scénario "gagnants et perdants" dans lequel les charges de travail se font concurrence. Vous avez peut-être une charge de travail OLTP qui rencontre un débit réduit en raison d'une requête de rapport exécutée en parallèle.
- Un autre problème peut être la rencontre d'un point de basculement :lorsque les limites globales de capacité et d'évolutivité de votre système sont atteintes à un certain point.
Je mentionne ces catégories globales comme point de départ, mais je sais qu'il peut souvent y avoir de fortes dépendances entre ces questions et qu'une catégorisation peut se fondre dans l'autre. Cela dit, la première étape consiste à définir les symptômes et les problèmes aussi clairement que possible.
Valider les conditions actuelles
Que le problème se soit produit dans le passé ou qu'il se produise actuellement, il est important d'obtenir autant d'informations générales que possible sur le système, la charge de travail et les configurations. Si vous utilisez des lignes de base et des run-books, idéalement, vous suivez déjà une grande partie de ces informations. Si ce n'est pas le cas, demandez-vous à quelle vitesse vous pourriez obtenir des réponses à ces questions à 2 heures du matin en pleine crise.
Les sous-sections suivantes couvrent des points de données importants qui m'intéressent généralement pour un problème de performances du processeur.
- Combien de sockets et de cœurs ?
- L'hyper-threading est-il activé ?
- Quel est le modèle de processeur, l'architecture (32 bits/64 bits) ?
- Est-ce un invité virtuel ?
- Si c'est le cas, vous serez désormais également intéressé par les détails concernant l'hôte et les autres invités virtuels avec lesquels vous partagez des ressources.
- Existe-t-il des paramètres liés au processeur ?
- Par exemple, processeur Hyper-V
- Combien de processeurs virtuels sont alloués aux invités ?
- Combien de processeurs virtuels cet invité possède-t-il ?
- L'invité a-t-il été récemment migré vers un nouvel hôte avant le problème ?
- Paramètre du degré maximal de parallélisme
- Seuil de coût pour l'option de parallélisme
- Paramètre d'affinité du processeur
- Paramètre de boost prioritaire
- Paramètre de nombre maximal de threads de travail
- Paramètre de mise en commun léger
- Quel est le paramètre d'option d'alimentation ? (niveau du système d'exploitation, VM Host ou BIOS contrôlé)
- Hautes performances, équilibré, économie d'énergie ?
- Est-il configuré au-delà des paramètres par défaut ?
- Voyez-vous des avertissements ou des erreurs inhabituels ?
Détails du serveur physique
Détails du serveur virtuel
Réserve, réservation de processeur VMware, poids relatif du processeur Hyper-V et parts de processeur VMware.
Paramètres de configuration de l'instance SQL Server
Les trois premières configurations peuvent nécessiter une discussion plus approfondie. Il y a rarement des absolus concernant ces paramètres.
En ce qui concerne les trois derniers paramètres, tels que "priority boost", si je vois qu'ils sont à des valeurs non par défaut, je vais certainement demander plus d'informations de fond et d'historique.
Paramètres des options d'alimentation du processeur
Les paramètres d'option d'alimentation sous "Hautes performances" sont encore très courants et ne doivent pas être ignorés pour les serveurs qui hébergent des instances SQL Server.
Configuration du gouverneur de ressources
Je trouve toujours qu'il est rare de rencontrer des clients utilisant cette fonctionnalité, mais il est facile de valider si elle est utilisée et cela en vaudra la peine pour les fois où elle est réellement configurée au-delà de la valeur par défaut.
Journal des erreurs SQL Server et journaux des événements Windows
Pourquoi rechercher dans les journaux d'erreurs et d'événements un problème de processeur ? Parfois, des problèmes en amont peuvent entraîner des problèmes de performances en aval dans SQL Server. Vous ne voulez pas perdre de temps à régler une requête ou à ajouter un nouvel index lorsque votre problème de cause première en amont est un problème de dégradation des composants matériels.
Répondez "Est-ce SQL Server ?"
Cela semble évident quand je le demande, mais vous ne voulez vraiment pas passer beaucoup de temps à résoudre un problème de processeur élevé dans SQL Server si le coupable n'est pas réellement SQL Server.
Au lieu de cela, prenez un moment pour vérifier quel processus consomme le plus de CPU. Vous avez le choix entre plusieurs options, notamment :
- Processus : % de temps utilisateur (mode utilisateur)
- Processus : % de temps privilégié (mode noyau)
- Gestionnaire de tâches
- Explorateur de processus
- Informations récentes sur le processeur via sys.dm_os_ring_buffers ou la session d'intégrité du système pour les instances spécifiques de SQL Server exécutées sur le système
S'il s'agit de SQL Server et que vous avez le choix entre plusieurs instances de SQL Server, assurez-vous de dépanner la bonne instance de SQL Server sur l'hôte. Il existe plusieurs façons de procéder, notamment l'utilisation de SELECT SERVERPROPERTY('processid') pour obtenir le PID, puis l'associer au gestionnaire de tâches ou à l'explorateur de processus.
Une fois que vous avez confirmé qu'il s'agit de SQL Server, constatez-vous un temps utilisateur élevé ou un temps privilégié (noyau) ? Encore une fois, cela peut être confirmé via Process:% Privileged Time (objet sqlservr) et également Windows Task Manager ou Process Explorer.
Bien que les problèmes de temps de noyau élevé devraient être rares, ils nécessitent toujours des chemins de dépannage différents des problèmes de dépannage de processeur de temps utilisateur standard. Certaines causes potentielles de temps de noyau élevé incluent des pilotes de filtre défectueux (antivirus, services de chiffrement), des mises à jour et des pilotes de micrologiciel obsolètes ou manquants, ou des composants d'E/S défectueux.
Identifier les consommateurs de CPU
Une fois que vous avez validé quelle instance de SQL Server gère l'utilisation du processeur en temps utilisateur sur le système, il existe de nombreux exemples de requêtes prédéfinis sur le Web que vous pouvez utiliser.
Vous trouverez ci-dessous une liste des DMV que les gens utilisent couramment sous diverses formes lors d'un problème de performances. J'ai structuré cela dans un format de questions-réponses pour vous aider à comprendre pourquoi vous voudriez y accéder.
- sys.dm_exec_requests
- sys.dm_exec_sql_text
- sys.dm_exec_sessions
- sys.dm_exec_connections
- sys.dm_exec_query_plan
- sys.dm_os_waiting_tasks
- sys.dm_exec_query_stats
- Agréger par total_worker_time
- Définir les moyennes avec execution_count
- S'il s'agit de charges de travail ad hoc, vous pouvez regrouper par query_hash
- Utilisez le plan_handle avec sys.dm_exec_query_plan pour saisir le plan
- sys.dm_os_tasks
- Classé par session_id, request_id
- sys.dm_exec_query_plan
- Regardez les opérateurs de plan, mais gardez à l'esprit qu'il ne s'agit que d'un plan estimé
- sys.dm_exec_query_stats
- Filtrer total_elapsed_time inférieur à total_worker_time
- Mais notez que cela peut être un faux négatif pour les scénarios de blocage - où la durée est gonflée en raison d'une attente sur la ressource
Quelles sont les requêtes en cours d'exécution et quel est leur état ?
Qu'est-ce qu'il exécute ?
D'où vient-il ?
Quel est son plan estimé ? (mais faites attention à ne pas déchiqueter xml sur un système déjà limité par le CPU)
Qui attend une ressource et qu'attend-elle ?
Quelles requêtes ont pris le plus de temps CPU depuis le dernier redémarrage ?
Cette requête utilise-t-elle le parallélisme ?
Faites correspondre le motif et résolvez
Vous riez probablement de cette étape particulière - car celle-ci peut être la plus impliquée (et c'est une autre raison pour laquelle les professionnels de SQL Server sont employés de manière lucrative). Il existe plusieurs modèles différents et des résolutions associées. Je terminerai donc cet article avec une liste des pilotes de problèmes de performances CPU les plus courants que j'ai vus au cours des dernières années :
- Opérations d'E/S élevées (et d'après mon expérience, il s'agit du pilote de processeur le plus courant)
- Problèmes d'estimation de cardinalité (et mauvaise qualité du plan de requête associé)
- Parallélisme inattendu
- Compilation/recompilation excessive
- Appels UDF gourmands en calculs, opérations de destruction
- Opérations ligne par ligne angoissantes
- Activités de maintenance simultanées (par exemple, UPDATE stats avec FULLSCAN)
Chaque domaine que j'ai identifié a un grand nombre de travaux associés à la recherche. En termes de ressources consolidées, je pense toujours que l'un des meilleurs est toujours l'article technique "Troubleshooting Performance Problems in SQL Server 2008" écrit par Sunil Agarwal, Boris Baryshnikov, Keith Elmore, Juergen Thomas, Kun Cheng et Burzin Patel.
Résumé
Comme pour toute méthodologie, il y a des limites à son utilisation et des domaines où vous êtes justifié d'improviser. Veuillez noter que je ne suggère pas que les étapes que j'ai décrites dans cet article soient utilisées comme un cadre rigide, mais considérez-les plutôt comme un point de lancement pour vos efforts de dépannage. Même les professionnels SQL Server très expérimentés peuvent faire des erreurs de débutant ou être biaisés par leurs expériences de dépannage les plus récentes, donc avoir une méthodologie minimale peut aider à éviter de résoudre le mauvais problème.
