Yüksek Disk G / Ç sql sunucusundan mı yoksa Yüksek disk G / Ç sql sunucusundan yavaşlıyor mu?

SQL sunucumuzdaki performans sorunları hakkında bir DBA ve birkaç donanım adamıyla tartışıyorum. Normalde her şey yolunda, ancak son birkaç hafta içinde sql sunucusunda büyük gecikme ani yaşıyoruz. SQL Server'ın disk G / Ç'de beklediği açıktır. Ama çünkü SQL Server anormal derecede yüksek G / Ç istediği söyleniyor. Durum böyle değil. Neyin koştuğunu görebiliyorum, normalin dışında hiçbir şey yok ve tüm DBA'nın bakması gereken engelleme ve benzeri şeylere neden olan şey, işe yaramaz. Örneğin, yedeklediğimiz en önemli şey, web sunucularında ASP Oturum Durumunu yönetmek için kullandığımız ASPState veritabanındaki işlemdir. Bu işlemler normalde Sp_who2 aktif sonuçlarında hiçbir zaman görülmez, çünkü çok hızlı gerçekleşirler. Veritabanı basit kurtarma modunda ve günlük kaydı miminal. Ancak bu gecikme sivri uçları sırasında, veritabanındaki çok sayıda seçme ve güncelleme işleminin engellendiğini veya beklediğini görebiliriz. Birisi ya da bir iş o veritabanları günlük ve veri dosyaları için kullanılan raid dizileri üzerinde heavey disk kullanımına neden olan bir şey çalışıyor eminim. Sorun bunu kanıtlıyor, çünkü kimse web sitemizi öldüren bir şey yaptığını itiraf etmek istemiyor.

Benim sorum ne performans sayaçları ya da SQL sunucusunun G / Ç'de beklediğini göstermeye yardımcı olacak her şeyi kaydedebilirim, ancak normalden daha fazlasını istediği için değil, bunun yerine disk sql sunucusundan gelen isteklere yanıt vermekle meşgul olduğu için değil normalde olduğu kadar hızlı?

Aşağıdaki perfmon sayaçlarına bir göz atın:

• SQL Server, Buffer Manager Nesnesi :
  Page lookups/sec
Page reads/sec
Readahead pages/sec
• SQL Server, Erişim Yöntemleri Nesnesi
  Full Scans/sec
Range Scans/sec
Skipped Ghosted Records/sec
• SQL Server, Bekleme İstatistikleri Nesnesi
  Page IO latch waits

Çok sayıda G / Ç isteğini kullanan SQL Server, çok sayıda tarama, sayfa arama ve sayfa okumalarındaki artış ve yüksek sayfa G / Ç mandal beklemeleri ile desteklenir. sys.dm_exec_query_statsYüksek fiziksel okuma sayıları olan girişler için bir göz atmaya değer . Suçluyu çabucak tespit edebilirlerdi.

Genelde soruna performans sorun giderme problemi olarak yaklaşırken, Bekleme ve Kuyruklar gibi bir metodolojiyi takip etmek doğru yaklaşımdır. Siz DBA sizin için doğru olanı yapıyor gibi görünüyor, bu yüzden onu dinlemelisiniz.

Başlamak için Glenn Berry'nin Diagnostic sorgularını ve Adam Machanic'in SP_Whoisactive'i kullanarak gerçekte ne olduğunu öğrenin.

Öncelikle bu sorguyu çalıştırarak hangi veritabanı dosyalarının en fazla GÇ darboğazına sahip olduğunu görün (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 );

Sonra sunucunuzun beklediği ilk on olayı görmek için bu sorguyu çalıştırın ( Jonathan Kehayias tarafından yapılan sorgu ). Ayrıca benzer sorgulama Glenn Berry tanı sorguları bulacaksınız.

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

Bu bilgileri elinize aldıktan sonra sorunu gidermek çok daha kolay olacaktır.

BTW burada sorun giderme için sp_whoisactive kullanımı ile ilgili birçok gönderi bulabilirsiniz .

"Sorun kanıtlıyor" dedi haklı olarak. SQL Server'a bir göz atın : Disk I / O'yu En Aza İndir

DMV'yi takip etmekten bahsediyor

sys.dm_io_virtual_file_stats
sys.dm_io_pending_io_requests

Referanslar:

1. SQL Server içinden G / Ç alt sistemi gecikmelerini inceleme
2. Glenn Berry'nin SQL Server Performansı - sys.dm_io_pending_io_requests