Transacciones muy altas por segundo

Nuestro servidor de producción ejecuta en promedio 4,000 transacciones por segundo. En los últimos días, el promedio ha aumentado a 175,000 transacciones por segundo. Eso no es un error tipográfico, es 175K por segundo.
Mirando las transacciones del DMV, no podemos vincularlo directamente a las sesiones de los usuarios, pero sí vemos esto:

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 |
+------------------------------+-------+

¿Alguien puede arrojar luz sobre este tipo de transacciones? ¿O estoy persiguiendo fantasmas aquí?

sql-server-2008 tempdb

— paulbarbin
fuente

Tal vez pueda perfilar el servidor ejecutando sp_whoisactive repetidamente. ¿Qué consultas surgen con mayor frecuencia?

— usr

Probablemente no está claro, pero en el texto original, dije que no hay correlación entre los procesos del usuario y las transacciones. Normalmente tenemos alrededor de 4000 usuarios conectados y en cualquier momento dado, entre 40 y 60 de ellos son spids ejecutables. Durante este período de transacción inflado, todavía había 40-60 spids ejecutables, sin diferencia.

— paulbarbin

Actualización: el tps ha vuelto a su valor normal y no vemos ninguna razón real para que suceda. Lo único que tiene sentido es que teníamos una consulta de servidor vinculada ejecutándose donde parecía que toda la tabla estaba siendo arrastrada a través del cable hacia tempdb. Ese proceso tardó mucho más de lo habitual. ¿Es posible que el tps se contara como 1 fila en la tabla = 1 transacción? La tabla tiene 50K filas y los usuarios la ejecutan ad hoc, por lo que 3 veces por segundo se llama y PODRÍA sumar, pero no parece probable.

— paulbarbin

Si fuera mi servidor, ejecutaría un rastreo rápido del lado del servidor. Tal vez solo un seguimiento de 5 minutos para ver si hay alguna posibilidad de que el conteo de tps sea falso. Definitivamente enviaría spam sp_whoisactive para observar consultas en vuelo también.

— Peter

Esté atento a la alta actividad nuevamente; cuando lo vea, inicie un rastreo del lado del servidor o, si es necesario, use Profiler brevemente para ver qué está sucediendo.

Alternativamente, use un sniffer de paquetes como Wireshark para capturar la actividad del cable sin procesar.

Verifique dm_exec_cached_plans para ver si eso da alguna idea de lo que está sucediendo.

Mire dm_io_virtual_file_stats para ver qué archivos en particular, si alguno, están siendo afectados.

— Contraseñas anti-débiles
fuente