web-dev-qa-db-fra.com

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 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 se passe 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 et ainsi de suite, ce qui est inutile. Par exemple, la principale chose que nous voyons en train de sauvegarder est l'opération 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 ils se produisent si rapidement. La base de données est en mode de récupération simple et la journalisation est criminelle. Cependant, pendant ces pics de décalage, nous pouvons voir beaucoup d'opérations de sélection et de mise à jour sur la base de données bloquées ou en attente. Je suis sûr que ce qui se passe est que quelqu'un ou un travail exécute quelque chose qui provoque une utilisation disproportionnée du disque sur les tableaux RAID utilisés pour le journal et les fichiers de données de la base 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 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?

sql-serverperfmon
18
Edgey

Jetez un œil aux compteurs perfmon suivants:

SQL Server entraînant un nombre élevé de demandes IO serait corroboré par un nombre élevé d'analyses, une augmentation des recherches de pages et des lectures de pages et une page haute IO attente de verrouillage). Vaut la peine d'essayer sys.dm_exec_query_stats pour les entrées avec un nombre élevé de lectures physiques. Ils pourraient rapidement identifier le coupable.

En général, aborder 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.

19
Remus Rusanu

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

Vérifiez d'abord quels fichiers de base de données ont le plus IO goulot d'étranglement 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 );

Ensuite, exécutez cette requête pour voir les dix principaux événements sur lesquels votre serveur attend (requête par 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.

12
DaniSQL

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

Il s'agit de suivre DMV

sys.dm_io_virtual_file_stats
sys.dm_io_pending_io_requests

Références:

  1. Comment examiner IO latences de sous-système à partir de SQL Server
  2. Performances SQL Server de Glenn Berry - sys.dm_io_pending_io_requests
1
LCJ