Transactions très élevées par seconde


8

Notre serveur de production exécute en moyenne 4 000 transactions par seconde. Au cours des derniers jours, la moyenne est passée à 175 000 transactions par seconde. Ce n'est pas une faute de frappe, c'est 175K par seconde.
En regardant les DMV pour les transactions, nous ne pouvons pas le lier directement aux sessions utilisateur, mais nous voyons ceci:

SELECT NAME,
       COUNT(*)
FROM   sys.dm_tran_active_transactions
GROUP  BY NAME
ORDER  BY 2 DESC 

-

+------------------------------+-------+
|             Name             | Count |
+------------------------------+-------+
| WorkFileGroup_fake_worktable |   627 |
| LobStorageProviderSession    |   217 |
| workfile                     |   171 |
+------------------------------+-------+

Quelqu'un peut-il faire la lumière sur ces types de transactions? Ou suis-je en train de chasser les fantômes ici?


Vous pouvez peut-être profiler le serveur en exécutant sp_whoisactive à plusieurs reprises. Quelles requêtes reviennent le plus souvent?
usr

Probablement pas clair mais dans le texte original, j'ai déclaré qu'il n'y a pas de corrélation entre les processus utilisateur et les transactions. Normalement, nous avons environ 4000 utilisateurs connectés et à un moment donné, entre 40 et 60 d'entre eux sont des spids exécutables. Pendant cette période de transaction gonflée, il y avait encore 40 à 60 spids exécutables - aucune différence.
paulbarbin

Mise à jour: le tps est revenu à sa valeur normale et nous ne voyons aucune raison réelle pour que cela se produise. La seule chose qui ait un sens est que nous avons eu une requête de serveur lié en cours d'exécution où il semblait que la table entière était tirée à travers le fil dans la tempdb. Ce processus prenait beaucoup plus de temps que d'habitude. Est-il possible que les tps soient comptés comme 1 ligne dans le tableau = 1 transaction ?? La table contient 50K lignes et elle est exécutée ad hoc par les utilisateurs, donc, 3 fois par seconde, elle est appelée et cela POURRAIT s'additionner, mais cela ne semble pas probable.
paulbarbin

2
Si c'était mon serveur, j'exécuterais une trace rapide côté serveur. Peut-être juste une trace de 5 minutes pour voir s'il y a une chance que le nombre de tps soit faux. Je pourrais certainement spammer sp_whoisactive pour observer également les requêtes en vol.
Peter

Réponses:


1

Surveillez à nouveau l'activité élevée; lorsque vous le voyez, démarrez une trace côté serveur ou, si nécessaire, utilisez brièvement le profileur pour voir ce qui se passe.

Alternativement, utilisez un renifleur de paquets comme Wireshark pour capturer l'activité des fils bruts.

Vérifiez dm_exec_cached_plans pour voir si cela donne une idée de ce qui se passe.

Regardez dm_io_virtual_file_stats pour voir quels fichiers en particulier, le cas échéant, sont touchés.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.