E / S disque élevé du serveur SQL ou E / S disque élevé ralentissant le serveur SQL?

Je me suis disputé avec un DBA et quelques gars du matériel sur les problèmes de performances sur notre serveur SQL. Normalement, tout va bien, mais au cours des dernières semaines, nous avons eu d'énormes pics de décalage dans le serveur SQL. Il est clair que SQL Server attend sur les E / S disque. Mais je n'arrête pas de me dire que c'est parce que SQL Server demande des E / S anormalement élevées. Ce qui n'est pas le cas. Je peux voir à partir de ce qui fonctionne qu'il n'y a rien hors de la normale, et tout ce que le DBA se soucie de regarder, c'est ce qui cause le blocage, etc., ce qui est inutile. Par exemple, la principale chose que nous voyons sauvegarder est le fonctionnement sur la base de données ASPState, que nous utilisons pour gérer l'état de session ASP sur les serveurs Web. Ces opérations ne sont normalement jamais vues sur les résultats actifs de Sp_who2 car elles se produisent si rapidement. La base de données est en mode de récupération simple et la journalisation est minime. Cependant, pendant ces pics de décalage, nous pouvons voir que de nombreuses opérations de sélection et de mise à jour sur la base de données sont bloquées ou en attente. Je suis sûr que ce qui se passe, c'est que quelqu'un ou un travail exécute quelque chose qui provoque une utilisation du disque Heavey sur les tableaux RAID utilisés pour ce journal de bases de données et les fichiers de données. Le problème le prouve, car personne ne veut admettre qu'il fait quelque chose qui tue notre site Web.

Ma question est de savoir quels compteurs de performances ou tout ce que je peux enregistrer pour aider à montrer que le serveur SQL attend sur les E / S, mais pas parce qu'il demande plus que la normale, car le disque est trop occupé pour répondre aux demandes du serveur SQL aussi rapidement que d'habitude?

Jetez un œil aux compteurs perfmon suivants:

• SQL Server, objet Buffer Manager :
  Page lookups/sec
Page reads/sec
Readahead pages/sec
• SQL Server, objet Méthodes d'accès
  Full Scans/sec
Range Scans/sec
Skipped Ghosted Records/sec
• SQL Server, objet Statistiques d'attente
  Page IO latch waits

SQL Server entraînant un nombre élevé de demandes d'E / S serait corroboré par un nombre élevé d'analyses, une augmentation des recherches et des lectures de pages et des attentes de verrouillage d'E / S de pages élevées. Cela vaut la peine d'essayer les sys.dm_exec_query_statsentrées avec un nombre élevé de lectures physiques. Ils pourraient rapidement identifier le coupable.

En général, en abordant le problème comme un problème de dépannage des performances, suivre une méthode comme Waits and Queues est la bonne approche. Vous DBA semble faire la bonne chose, vous devriez donc l'écouter.

Pour commencer, utilisez les requêtes de diagnostic de Glenn Berry et SP_Whoisactive d'Adam Machanic pour découvrir ce qui se passe réellement.

Vérifiez d'abord quels fichiers de base de données ont le plus de goulots d'étranglement d'E / S en exécutant cette requête (Query by 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 );

Exécutez ensuite cette requête pour voir les dix principaux événements sur lesquels votre serveur attend (requête de Jonathan Kehayias ). Vous trouverez également une requête similaire à partir des requêtes de diagnostic 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

Une fois que vous disposez de ces informations, il serait beaucoup plus facile de résoudre le problème.

BTW, vous pouvez trouver de nombreux messages sur la façon d'utiliser sp_whoisactive pour le dépannage ici.

"Le problème le prouve", a déclaré à juste titre. Jetez un œil à SQL Server: réduire les E / S disque

Il s'agit de suivre DMV

sys.dm_io_virtual_file_stats
sys.dm_io_pending_io_requests

Les références:

1. Comment examiner les latences du sous-système d'E / S à partir de SQL Server
2. Performances de SQL Server de Glenn Berry - sys.dm_io_pending_io_requests