I / O Disk Tinggi dari sql server atau I / O disk tinggi memperlambat server sql?


18

Saya telah berdebat dengan DBA dan beberapa orang tentang masalah kinerja pada server SQL kami. Biasanya semuanya baik-baik saja, namun selama beberapa minggu terakhir kami telah mengalami lonjakan lag besar di server sql. Jelas bahwa SQL Server menunggu pada disk I / O. Tapi saya terus diberitahu bahwa itu karena SQL Server meminta I / O tinggi yang tidak normal. Yang tidak demikian. Saya bisa melihat dari apa yang berjalan bahwa tidak ada yang di luar normal, dan semua DBA peduli untuk melihat adalah apa yang menyebabkan pemblokiran dan sebagainya, yang tidak berguna. Sebagai contoh, hal utama yang kami lihat cadangannya adalah operasi pada basis data ASPState, yang kami gunakan untuk mengelola ASP Session State di server web. Operasi ini biasanya tidak pernah terlihat pada hasil aktif Sp_who2 karena mereka terjadi begitu cepat. Basis data dalam mode pemulihan sederhana dan pencatatan adalah miminal. Namun selama lonjakan lag ini kita bisa melihat banyak pilih dan memperbarui operasi pada database yang diblokir atau menunggu. Saya yakin apa yang terjadi adalah bahwa seseorang atau beberapa pekerjaan sedang menjalankan sesuatu yang menyebabkan penggunaan disk heavey pada array raid yang digunakan untuk basis data log dan file data. Masalahnya adalah membuktikannya, karena tidak ada yang mau mengakui bahwa mereka melakukan sesuatu yang mematikan situs web kami.

Pertanyaan saya adalah apa penghitung kinerja atau apa pun yang bisa saya login yang akan membantu menunjukkan bahwa server SQL menunggu di I / O, tetapi bukan karena meminta lebih dari biasanya, bukan karena disk sibuk untuk menanggapi permintaan dari sql server secepat biasanya?


3
Negara tunggu apa yang sebenarnya Anda lihat, Jaringan I / O? yaitu, apakah Anda menggunakan SAN?
Eric Higgins

Periksa untuk melihat apakah Anda memiliki pertanyaan yang mendominasi penggunaan sumber daya di server DB. Jika ada, coba setel itu. Jika Anda tidak memiliki kueri yang berperilaku buruk, maka menunggu PAGEIOLATCH tinggi biasanya akan menunjukkan sistem Anda terikat I / O. Juga, seperti yang dikatakan @EricHiggins, SAN seringkali lambat dan menyebabkan masalah kinerja dengan database.
ConcernedOfTunbridgeWells

Ini adalah array NETAPP yang terhubung ke server sql dengan Qlogic fiber HBA's.
Edgey

Saya tahu ini adalah pertanyaan yang relatif lama, dan ini tidak akan secara langsung memperbaiki masalah Anda ... tapi kami beralih ke aspnet_state.exe untuk status sesi dan melihat banyak beban dari SQL Server kami. Ini tidak didokumentasikan dengan baik tetapi cukup mudah untuk diatur.
MattGWagner

Jadi apa yang akhirnya Anda / DBA lakukan dan apa masalahnya?
Mukus

Jawaban:


19

Lihatlah penghitung perfmon berikut:

SQL Server yang menggerakkan sejumlah besar permintaan IO akan dikuatkan dengan pemindaian angka yang tinggi, peningkatan dalam pencarian halaman dan pembacaan halaman serta menunggu latch IO halaman yang tinggi. Layak untuk dicoba melihat sys.dm_exec_query_statsentri dengan jumlah pembacaan fisik yang tinggi. Mereka bisa dengan cepat menunjukkan pelakunya.

Secara umum mendekati masalah sebagai masalah pemecahan masalah kinerja, mengikuti metodologi seperti Waits dan Antrian adalah pendekatan yang tepat. Anda DBA tampaknya melakukan hal yang benar sehingga Anda harus mendengarkannya.


Saya tidak punya masalah dengan DBA dia adalah salah satu DBA terbaik yang pernah saya kerjakan. Dan dia memberi saya daftar prosedur penyimpanan tinggi yang diblokir. Tetapi seperti yang saya sebutkan salah satu procs yang menyebabkan banyak pemblokiran adalah "TempUpdateStateItemLong" yang merupakan proc yang digunakan oleh hte SQL Session state store. Ini adalah MS proc, dan itu hanya memperbarui satu tabel oleh sessionID yang merupakan kunci utama yang diindeks di atas meja. Paling-paling tabel ini memiliki 2000-3000 catatan, jadi pembaruan benar-benar tidak memerlukan waktu sama sekali.
Edgey

Ini tempat yang bagus untuk memulai. Kami masih menjalankan SQL Server 2000, kami sedang dalam proses peningkatan tetapi itu tidak akan terjadi selama beberapa bulan lagi, jadi saya tidak memiliki PAge IO Latch menunggu counter untuk melihatnya. Terima kasih lagi.
Edgey

Perhatikan bahwa pemblokiran per-se tidak menyiratkan IO tinggi. Itu bisa menjadi pertikaian kunci, dan itu akan memengaruhi tabel tidak peduli ukurannya, khususnya jika optimizer memilih paket berbasis pemindaian tabel.
Remus Rusanu

Dan juga periksa Proses untuk IO Data Bytes/secdan melihat apakah beberapa proses lain adalah menghancurkan disk.
Remus Rusanu

12

Untuk mulai menggunakan pertanyaan Diagnostik Glenn Berry dan SP_Whoisactive Adam Machanic untuk mencari tahu apa yang sebenarnya terjadi.

Pertama-tama lihat file database mana yang paling banyak mengalami hambatan IO dengan menjalankan kueri ini (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 );

Kemudian jalankan kueri ini untuk melihat sepuluh peristiwa teratas yang ditunggu server Anda (permintaan oleh Jonathan Kehayias ). Anda juga akan menemukan permintaan serupa dari permintaan diagnostik 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

Setelah Anda memiliki informasi ini, akan lebih mudah untuk memecahkan masalah.

BTW Anda dapat menemukan banyak posting tentang cara menggunakan sp_whoisactive untuk pemecahan masalah di sini.


1
Saya hanya menggunakan skrip terakhir dalam daftar ini - tendangannya.
the_good_pony

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.