Quelle est la fréquence des déversements de hachage / tri dans tempdb?

Notre application d'entreprise utilise SQL Server pour le stockage de données et est principalement un système OLTP. Cependant, un composant important de notre application génère une charge de travail OLAP importante.

Notre latence d'écriture sur tempdb est d'environ 100 ms. Cette tendance se maintient avec le temps et ALLOW_SNAPSHOT_ISOLATIONest désactivée . Nous sommes en train de résoudre ce problème et la seule chose intéressante que nous ayons trouvée jusqu'à présent est qu'il existe un nombre important de déversements de hachage et de tri dans tempdb. Nous supposons que cela vient de notre charge de travail OLAP.

Question

Quelle est la fréquence des déversements? Tout? Combien de déversements / sec? Nos données préliminaires indiquent que nous avons environ 2 déversements de hachage par seconde et 25 déversements de tri par minute.

Est-il possible que cette fréquence de déversements soit un des principaux responsables de notre latence d'écriture à haute température?

Les autres informations

Nous utilisons plusieurs fichiers pour tempdb comme recommandé par nombre de cœurs. Les fichiers tempdb se trouvent sur un SAN RAID 1 + 0 (avec des SSD hautes performances), mais il s'agit du même périphérique que les données DB et les fichiers journaux principaux. Les fichiers tempdb sont suffisamment volumineux pour se développer très rarement. Nous n'utilisons pas d'indicateurs de trace 1117 ou 1118. Une autre variable est que cette configuration est partagée pour un certain nombre de bases de données différentes qui connaissent toutes une charge moyenne à élevée.

Notre latence d'écriture de 100 ms est bien supérieure aux plages acceptables de latence d'écriture tempdb que nous avons trouvées sur MSDN, SQL Skills et d'autres sites. Cependant, la latence d'écriture pour nos autres bases de données est bonne (inférieure à 10 ms). Sur la base d'autres statistiques, il semble que nous utilisons beaucoup tempdb, en particulier pour les objets internes. Nous cherchons donc à découvrir pourquoi notre application utilise si fortement les objets internes.

Nous avons de réels problèmes de performances sur notre plate-forme qui se manifestent de différentes manières. Nous avons surveillé les compteurs de performances, examiné les vues DM et analysé le comportement de notre application pour essayer de creuser dans les caractéristiques d'utilisation des ressources de notre système. Nous nous concentrons sur les déversements en ce moment car nous avons lu que les déversements ont un impact négatif drastique car ils sont effectués sur le disque plutôt qu'en mémoire. Et nous semblons avoir un très grand nombre de déversements, mais je voulais obtenir des commentaires sur ce que les gens considèrent comme «élevé».

Est-il possible que cette fréquence de déversements soit un des principaux responsables de notre latence d'écriture à haute température?

Oui, c'est possible , bien que ce soit généralement la taille moyenne des déversements et leur profondeur (c'est-à-dire les déversements de hachage récursifs, les types à passages multiples) qui importent plus que la fréquence en soi.

SQL Server fournit une large gamme de mesures et d'informations DMV pour vous aider à résoudre les divers facteurs contribuant à la pression de tempdb, dont beaucoup sont abordés dans l'article technique de Microsoft, «Utilisation de tempdb dans SQL Server 2005» (s'applique à toutes les versions à partir de 2005) ).

Vous devriez pouvoir utiliser les requêtes de guidage et de diagnostic contenues dans ce document pour commencer à identifier les principales causes de toute pression tempdb. Ne négligez pas par exemple l'activité du magasin de versions simplement parce qu'elle ALLOW_SNAPSHOT_ISOLATIONn'est pas activée. De nombreuses fonctionnalités utilisent le magasin de versions (par exemple les déclencheurs, MARS, RCSI) en dehors de l'isolement de l'instantané.

Si les déversements de tri et de hachage s'avèrent importants à un niveau élevé, vous devrez probablement mettre en place une surveillance spécifique à cet effet. En fonction un peu de votre version de SQL Server, ce n'est pas toujours simple comme on pourrait l'espérer. Pour connecter les déversements de tri et de hachage à la requête particulière qui les a provoqués, il faut des notifications d'événement ou des événements étendus. L'article de SolidQ, " Identification et résolution des avertissements de tri " contient des détails et quelques bons conseils généraux sur la résolution des causes courantes.

Vous devez également travailler avec votre équipe de stockage pour déterminer quelle part de la latence élevée est attribuable à votre charge de travail, quelle part provient d'autres utilisations partagées et quelles sont les options de reconfiguration. Votre analyse des métriques de SQL Server aidera à éclairer cette discussion, de même que toutes les métriques que les personnes SAN sont en mesure de fournir.