Le dépannage des performances est un art et une science. L'art vient de l'expérience (et de l'apprentissage des expériences des autres) et la science vient de directives bien connues sur ce qu'il faut faire dans quels scénarios.
Ou du moins c'est ce que j'aime penser et enseigner.
En réalité, de nombreux administrateurs de bases de données et développeurs pratiquent ce que j'appelle le « dépannage des performances par réflexe ». Cela se produit généralement lorsqu'un problème de performances a atteint un stade critique avec, par exemple, des requêtes qui expirent, des processus qui s'exécutent lentement ou échouent, des utilisateurs mécontents et la direction qui veut des réponses et une action rapide !
Le `` réflexe '' vient de faire une analyse superficielle du problème et de sauter à la conclusion (vraiment, c'est saisir une paille) que le symptôme le plus répandu doit être la cause profonde et essayer de résoudre ce problème, en vain ou peu, utilisant souvent des conseils erronés ou carrément incorrects trouvés en ligne. Cela entraîne beaucoup de frustration et de perte de temps, et conduit souvent à un gaspillage d'argent lorsque l'organisation décide d'essayer de résoudre le problème avec du matériel en mettant à niveau le serveur et/ou le sous-système d'E/S, pour découvrir que le problème est toujours là. , ou réapparaît assez rapidement.
L'analyse des statistiques d'attente est l'un des domaines où il est le plus facile de réagir, et dans cet article, je vais parler de quelques-uns des types d'attente courants et des erreurs que les gens commettent autour d'eux. Il n'y a pas de place dans un article comme celui-ci pour approfondir ce qu'il faut faire dans chaque cas, mais je vais vous donner suffisamment d'informations pour vous orienter dans la bonne direction.
LCK_M_XX
La plupart des gens supposent que si les attentes de verrouillage sont les plus répandues, il doit s'agir d'un problème de blocage. C'est souvent le cas, comme l'absence d'un index non cluster approprié provoquant une analyse de table dans les niveaux d'isolement REPEATABLE_READ ou SERIALIZABLE qui se transforme en un verrou de table S. (Et comme un indice rapide, si vous pensez ne jamais utiliser SERIALIZABLE, vous le faites si vous utilisez des transactions distribuées - tout est converti en SERIALIZABLE sous les couvertures, ce qui peut entraîner des blocages et des blocages inattendus.)
Cependant, il arrive souvent que le blocage soit causé par autre chose. Sous le niveau d'isolation par défaut READ_COMMITTED, les verrous couvrant les modifications sont maintenus jusqu'à ce que la transaction soit validée, et bloqueront les lectures et autres mises à jour de la ou des mêmes lignes. Si quelque chose empêche une transaction de s'engager, cela pourrait entraîner l'apparition d'un blocage.
Par exemple, si la base de données est mise en miroir de manière synchrone, la transaction ne peut pas valider et libérer ses verrous tant que les enregistrements du journal n'ont pas été envoyés au miroir et écrits sur le lecteur de journal du miroir. Si le réseau est fortement encombré ou s'il y a un conflit d'E / S massif sur le miroir, cela pourrait sérieusement retarder l'opération de mise en miroir et donc rendre la transaction beaucoup plus longue à valider. Cela ressemblerait à un blocage, mais la cause principale est un conflit de ressources lié à la mise en miroir.
Pour les attentes de verrouillage, à moins que la cause ne soit évidente en examinant le plan de requête, verrouillez la ressource (par exemple, au niveau de la table indiquant l'escalade de verrous ou le niveau d'isolement, suivez la chaîne de blocage (à l'aide d'un script qui parcourt la colonne blocking_session_id dans sys.dm_exec_requests, puis regardez ce qu'attend le fil à la tête de la chaîne de blocage. Cela indiquera la cause première.
ASYNC_NETWORK_IO
Le nom de celui-ci prête à beaucoup de confusion. Sur quel mot vous concentrez-vous ? RÉSEAU. La cause de ce type d'attente n'a généralement rien à voir avec le réseau. Il devrait vraiment s'appeler WAITING_FOR_APP_ACK (nowledgment), ou quelque chose de similaire, car c'est exactement ce qui se passe :SQL Server a envoyé des données à un client et attend que le client reconnaisse qu'il a consommé les données.
L'une de mes démonstrations préférées à faire lors de l'enseignement des statistiques d'attente consiste à exécuter une requête qui renvoie un grand ensemble de résultats dans Management Studio et à regarder le serveur accumuler les attentes ASYNC_NETWORK_IO. Il n'y a clairement aucun réseau impliqué - c'est juste que SSMS prend beaucoup de temps pour répondre à SQL Server. Il fait ce qu'on appelle RBAR (Row-By-Agonizing-Row), où une seule ligne à la fois est extraite des résultats et traitée, au lieu de mettre en cache tous les résultats, puis de répondre immédiatement à SQL Server et de traiter le lignes en cache.
C'est la principale cause des attentes ASYNC_NETWORK_IO - une mauvaise conception de l'application. Je regarderais ensuite si le serveur exécutant le code d'application a un problème de performances, même si le code d'application lui-même est bien conçu. Parfois, c'est le réseau, mais c'est rare d'après mon expérience.
OLEDB
La réaction instinctive courante ici consiste à assimiler ce type d'attente à des serveurs liés. Cependant, ce temps d'attente est devenu plus courant lors de la livraison de SQL Server 2005, car 2005 contenait une série de nouveaux DMV, et les DMV utilisent principalement OLE DB sous les couvertures. Avant de rechercher des problèmes de serveur lié, je vérifierais si un outil de surveillance exécute constamment des DMV sur le serveur.
Si vous avez des serveurs liés, poursuivez le dépannage en accédant au serveur lié et en consultant les statistiques d'attente pour voir quel est le problème le plus courant, puis poursuivez la même analyse.
Une autre chose qui peut provoquer des attentes OLEDB est DBCC CHECKDB (et les commandes associées). Il utilise un ensemble de lignes OLE DB pour communiquer des informations entre ses sous-systèmes de processeur de requêtes et de moteur de stockage.
Autres temps d'attente
Certaines des autres attentes qui provoquent des réactions instinctives sont CXPACKET, PAGEIOLATCH_XX, SOS_SCHEDULER_YIELD et WRITELOG, et je les couvrirai dans mon article le mois prochain.
Résumé
Lorsque vous rencontrez un problème de performances, prenez le temps de comprendre les données que vous examinez et effectuez des recherches plus approfondies pour vous aider à déterminer la cause première du problème. Ne vous contentez pas de saisir ce qui semble être la principale statistique d'attente et suivez le premier conseil que vous rencontrez en ligne (à moins qu'il ne provienne d'une source bien connue et réputée) ou vous ne résoudrez probablement pas votre problème, et peut même empirer les choses.
En ce qui concerne les statistiques d'attente générales, vous pouvez trouver plus d'informations sur leur utilisation pour le dépannage des performances dans :
- Ma série d'articles de blog, en commençant par les statistiques d'attente, ou s'il vous plaît dites-moi où ça fait mal
- Bibliothèque de mes types d'attente et de mes classes de verrouillage ici
- Ma formation en ligne Pluralsight SQL Server :Dépannage des performances à l'aide des statistiques d'attente
- Conseiller de performances SQL Sentry
C'était le premier d'une série de messages que je ferai au cours de cette année qui parlent des (ré)actions instinctives autour de SQL Server et pourquoi ce n'est pas la bonne chose à faire. Jusqu'à la prochaine fois, bon dépannage !
