High Disk I / O del servidor SQL o ¿High Disk I / O está ralentizando el servidor SQL?

18

He estado discutiendo con un DBA y un par de expertos en hardware sobre problemas de rendimiento en nuestro servidor SQL. Normalmente todo está bien, sin embargo, en las últimas semanas hemos tenido grandes picos de retraso en el servidor SQL. Está claro que SQL Server está esperando en la E / S del disco. Pero me siguen diciendo que es porque SQL Server está pidiendo E / S anormalmente altas. Que no es el caso. Puedo ver por lo que se está ejecutando que no hay nada fuera de lo normal, y todo lo que el DBA tiene en cuenta es qué está causando el bloqueo, etc., lo que es inútil. Por ejemplo, lo más importante que vemos es una operación de respaldo en la base de datos ASPState, que estamos usando para administrar el estado de sesión ASP en los servidores web. Estas operaciones normalmente nunca se ven en los resultados activos de Sp_who2 porque ocurren muy rápido. La base de datos está en modo de recuperación simple y el registro es miminal. Sin embargo, durante estos picos de retraso podemos ver muchas operaciones de selección y actualización en la base de datos bloqueada o en espera. Estoy seguro de que lo que está sucediendo es que alguien o algún trabajo está ejecutando algo que está causando el uso del disco pesado en las matrices de incursiones utilizadas para ese registro de bases de datos y archivos de datos. El problema lo está demostrando, ya que nadie quiere admitir que están haciendo algo que está matando nuestro sitio web.

Mi pregunta es qué contadores de rendimiento o cualquier cosa que pueda registrar que ayudará a mostrar que el servidor SQL está esperando E / S, pero no porque está pidiendo más de lo normal, sino porque el disco está ocupado para responder a las solicitudes del servidor SQL tan rápido como lo haría normalmente?

sql-server perfmon Edgey
fuente
3
¿Qué estado de espera estás viendo realmente, E / S de red? es decir, ¿estás usando una SAN?
Eric Higgins
Verifique si tiene alguna consulta que domine el uso de recursos en el servidor de base de datos. Si los hay, intente ajustarlos. Si no tiene consultas que se comporten mal, las altas esperas de PAGEIOLATCH generalmente indicarán que su sistema está vinculado a E / S. Además, como dice @EricHiggins, las SAN a menudo son lentas y causan problemas de rendimiento con las bases de datos.
Preocupado por
Es una matriz NETAPP conectada al servidor sql con HBA de fibra Qlogic.
Edgey
Sé que esta es una pregunta relativamente antigua, y esto no solucionará directamente su problema ... pero cambiamos a aspnet_state.exe para el estado de sesión y vimos una gran carga de nuestro SQL Server. No está bien documentado pero es bastante fácil de configurar.
MattGWagner
Entonces, ¿qué terminaron haciendo ustedes / el DBA y cuál fue el problema?
Mukus

Respuestas:

19

Echa un vistazo a los siguientes contadores de perfmon:

SQL Server que maneja una gran cantidad de solicitudes de E / S se corroboraría con una gran cantidad de escaneos, un aumento en las búsquedas de páginas y lecturas de páginas y altas esperas de bloqueo de E / S de páginas. Vale la pena probar las sys.dm_exec_query_statsentradas con un alto recuento de lecturas físicas. Podrían localizar rápidamente al culpable.

En general, abordar el problema como un problema de resolución de problemas de rendimiento, seguir una metodología como Waits and Queues es el enfoque correcto. Tu DBA parece estar haciendo lo correcto, así que deberías escucharlo.

Remus Rusanu
fuente
No tengo ningún problema con el DBA, es uno de los mejores DBA con los que he trabajado. Y me ha dado una lista de procedimientos almacenados de alto bloqueo. Pero como mencioné, uno de los procesos que está causando mucho bloqueo es "TempUpdateStateItemLong", que es un proceso utilizado por el almacén de estado de la sesión SQL. Es un proceso de MS, y solo actualiza una sola tabla por el ID de sesión, que es la clave primaria indexada en la tabla. Además, como máximo, esta tabla tiene 2000-3000 registros, por lo que las actualizaciones realmente no deberían tomar tiempo.
Edgey
Este es un buen lugar para comenzar. Todavía estamos ejecutando SQL Server 2000, estamos en el proceso de actualización, pero eso no sucederá durante unos meses más, por lo que no tengo el contador de espera PAge IO Latch para mirar. Gracias de nuevo.
Edgey
Tenga en cuenta que el bloqueo per-se no implica un alto IO. Podría ser una contención de bloqueo, y eso afectaría la tabla sin importar el tamaño, especialmente si el optimizador elige un plan basado en el escaneo de la tabla.
Remus Rusanu
Y también verifique el Proceso para IO Data Bytes/secver si algún otro proceso está destruyendo el disco.
Remus Rusanu
12

Para comenzar, use las consultas de diagnóstico de Glenn Berry y SP_Whoisactive de Adam Machanic para averiguar qué está sucediendo realmente.

Primero vea qué archivos de la base de datos tienen el mayor cuello de botella de IO ejecutando esta consulta (Consulta de Glenn Berry)

SELECT  DB_NAME(fs.database_id) AS [Database Name] ,
        mf.physical_name ,
        io_stall_read_ms ,
        num_of_reads ,
        CAST(io_stall_read_ms / ( 1.0 + num_of_reads ) AS NUMERIC(10, 1)) AS [avg_read_stall_ms] ,
        io_stall_write_ms ,
        num_of_writes ,
        CAST(io_stall_write_ms / ( 1.0 + num_of_writes ) AS NUMERIC(10, 1)) AS [avg_write_stall_ms] ,
        io_stall_read_ms + io_stall_write_ms AS [io_stalls] ,
        num_of_reads + num_of_writes AS [total_io] ,
        CAST(( io_stall_read_ms + io_stall_write_ms ) / ( 1.0 + num_of_reads
                                                          + num_of_writes ) AS NUMERIC(10,
                                                              1)) AS [avg_io_stall_ms]
FROM    sys.dm_io_virtual_file_stats(NULL, NULL) AS fs
        INNER JOIN sys.master_files AS mf WITH ( NOLOCK ) ON fs.database_id = mf.database_id
                                                             AND fs.[file_id] = mf.[file_id]
ORDER BY avg_io_stall_ms DESC
OPTION  ( RECOMPILE );

Luego ejecute esta consulta para ver los diez eventos principales que su servidor está esperando (consulta de Jonathan Kehayias ). También encontrará consultas similares en las consultas de diagnóstico de Glenn Berry.

SELECT TOP 10
        wait_type ,
        max_wait_time_ms wait_time_ms ,
        signal_wait_time_ms ,
        wait_time_ms - signal_wait_time_ms AS resource_wait_time_ms ,
        100.0 * wait_time_ms / SUM(wait_time_ms) OVER ( ) AS percent_total_waits ,
        100.0 * signal_wait_time_ms / SUM(signal_wait_time_ms) OVER ( ) AS percent_total_signal_waits ,
        100.0 * ( wait_time_ms - signal_wait_time_ms )
        / SUM(wait_time_ms) OVER ( ) AS percent_total_resource_waits
FROM    sys.dm_os_wait_stats
WHERE   wait_time_ms > 0 -- remove zero wait_time
        AND wait_type NOT IN -- filter out additional irrelevant waits
( 'SLEEP_TASK', 'BROKER_TASK_STOP', 'BROKER_TO_FLUSH', 'SQLTRACE_BUFFER_FLUSH',
  'CLR_AUTO_EVENT', 'CLR_MANUAL_EVENT', 'LAZYWRITER_SLEEP', 'SLEEP_SYSTEMTASK',
  'SLEEP_BPOOL_FLUSH', 'BROKER_EVENTHANDLER', 'XE_DISPATCHER_WAIT',
  'FT_IFTSHC_MUTEX', 'CHECKPOINT_QUEUE', 'FT_IFTS_SCHEDULER_IDLE_WAIT',
  'BROKER_TRANSMITTER', 'FT_IFTSHC_MUTEX', 'KSOURCE_WAKEUP',
  'LAZYWRITER_SLEEP', 'LOGMGR_QUEUE', 'ONDEMAND_TASK_QUEUE',
  'REQUEST_FOR_DEADLOCK_SEARCH', 'XE_TIMER_EVENT', 'BAD_PAGE_PROCESS',
  'DBMIRROR_EVENTS_QUEUE', 'BROKER_RECEIVE_WAITFOR',
  'PREEMPTIVE_OS_GETPROCADDRESS', 'PREEMPTIVE_OS_AUTHENTICATIONOPS', 'WAITFOR',
  'DISPATCHER_QUEUE_SEMAPHORE', 'XE_DISPATCHER_JOIN', 'RESOURCE_QUEUE' )
ORDER BY wait_time_ms DESC

Una vez que tenga esta información a mano, sería mucho más fácil solucionar el problema.

Por cierto, puedes encontrar muchas publicaciones sobre cómo usar sp_whoisactive para la resolución de problemas aquí.

DaniSQL
fuente
1
Acabo de usar el guión final en esta lista: es increíble.
the_good_pony