Kembali pada tahun 2014, saya memulai serangkaian posting blog di sini untuk berbicara tentang jenis menunggu tertentu dan apa yang mereka lakukan dan tidak maksudkan. Itu memberi saya ide untuk membuat library wait and latches yang saya pertahankan (lebih lanjut tentang ini nanti).
Jika Anda membaca ini dan berpikir "apa yang dia bicarakan?" maka posting ini adalah untuk Anda. Saya akan memperkenalkan Anda untuk menunggu statistik dan menjelaskan betapa pentingnya mereka untuk memecahkan masalah kinerja beban kerja di SQL Server.
Penjadwalan
Eksekusi kode internal SQL Server dilakukan menggunakan mekanisme yang disebut utas . Setiap utas dapat mengeksekusi kode SQL Server, dan beberapa utas berkoordinasi bersama saat kueri berjalan secara paralel. Utas ini dibuat saat SQL Server dimulai, bergantung pada jumlah inti prosesor yang tersedia untuk digunakan SQL Server.
Utas ditempatkan pada penjadwal saat kueri dimulai, dengan satu penjadwal per inti prosesor, dan jangan keluar dari penjadwal tersebut hingga kueri selesai. Penjadwal memiliki tiga 'bagian' dasar:
- prosesor , yang memiliki tepat satu utas yang sedang mengeksekusi kode.
- Daftar pelayan , yang memiliki semua utas yang pada dasarnya macet, menunggu sumber daya tertentu tersedia.
- Antrian yang dapat dijalankan , yang memiliki semua utas yang dapat dieksekusi tetapi menunggu untuk masuk ke prosesor.
Transisi utas dari status 1 ke 2 ke 3 ke 1, berputar-putar hingga kueri selesai.
Menunggu
Dari sudut pandang kami, bagian paling menarik dari penjadwalan adalah saat utas harus menunggu sumber daya sebelum dapat melanjutkan. Beberapa contohnya adalah:
- Sebuah thread perlu membaca sebuah halaman, dan halaman tersebut tidak ada dalam memori, sehingga thread tersebut mengeluarkan I/O fisik asinkron dan kemudian harus menunggu, di luar prosesor, hingga I/O selesai.
- Sebuah utas perlu memperoleh kunci berbagi pada satu baris untuk membacanya, tetapi utas lain sudah memegang kunci eksklusif yang bertentangan saat sedang memperbarui baris.
Ketika sebuah utas menemukan kebutuhan akan sumber daya yang tidak dapat diperolehnya, ia tidak memiliki pilihan selain berhenti dan menunggu sumber daya tersedia (mekanisme bagaimana utas diberitahu tentang ketersediaan sumber daya berada di luar cakupan artikel ini). Ketika itu terjadi, SQL Server membuat catatan mengapa utas harus menunggu dan ini disebut tipe tunggu . Beberapa contohnya adalah:
- Saat sebuah thread menunggu halaman untuk dibaca ke dalam memori agar bisa dibaca, tipe menunggunya adalah PAGEIOLATCH_SH (jika utas menunggu halaman yang akan diubah, jenis tunggunya adalah PAGEIOLATCH_EX ).
- Saat utas menunggu kunci berbagi pada baris, jenis tunggu adalah LCK_M_S (kunci-mode-berbagi)
SQL Server juga melacak berapa lama utas harus menunggu. Ini disebut waktu tunggu sumber daya , dan biasanya hanya dikenal sebagai waktu tunggu .
Statistik Tunggu
Kumpulan metrik keseluruhan tentang berapa banyak utas yang telah menunggu sumber daya mana dan untuk berapa lama rata-rata disebut statistik tunggu . Informasi ini sangat berguna untuk memecahkan masalah kinerja beban kerja, karena Anda dapat dengan mudah melihat di mana hambatan kinerja mungkin terjadi.
Ide dasarnya adalah bahwa SQL Server memiliki informasi tentang mengapa utas harus berhenti dan menunggu, dan apa yang mereka tunggu. Jadi, daripada harus menebak dari mana harus memulai pemecahan masalah, analisis statistik tunggu yang cermat biasanya dapat mengarahkan Anda ke arah yang harus diambil.
Misalnya, jika sebagian besar waktu tunggu di server adalah PAGEIOLATCH_SH , ini mungkin menunjukkan bahwa ada tekanan memori di server, atau ada kueri yang melakukan pemindaian tabel besar alih-alih menggunakan indeks nonclustered, atau ada masalah dengan subsistem I/O yang mendasarinya, atau sejumlah alasan lainnya.
Ada banyak jenis menunggu tetapi kebanyakan tidak sering muncul, jadi ada kumpulan inti yang akan Anda lihat berulang kali di server Anda. Memahami apa artinya ini dan bagaimana menyelidikinya sangat penting sehingga Anda tidak menyerah pada apa yang saya sebut 'penyetelan kinerja spontan' dan membuang waktu dan upaya untuk mencoba memperbaiki masalah yang sebenarnya bukan masalah. Saya menulis serangkaian posting blog di sini yang membahas detail di sana, dan Aaron Bertrand juga menulis posting ringkasan dari 10 statistik penantian teratas tahun lalu.
Melacak Menunggu
Ada beberapa cara untuk melacak waktu tunggu. Yang paling sederhana adalah melihat apa yang menunggu yang terjadi di server sekarang, menggunakan skrip yang memeriksa sys.dm_os_waiting_tasks DMV. Anda dapat menemukan skrip untuk melakukannya di sini, dan skrip tersebut memiliki URL yang dibuat secara otomatis ke pustaka tunggu.
Cara lain adalah dengan melihat statistik tunggu agregat untuk seluruh server, dengan skrip yang memeriksa sys.dm_os_wait_stats DMV. Anda dapat menemukan skrip untuk melakukannya di sini, dan itu memiliki URL yang dibuat secara otomatis ke pustaka tunggu. Anda harus berhati-hati dengan metode itu, karena itu akan menunjukkan semua penantian yang telah terjadi sejak server dimulai. Cara yang lebih baik adalah melacak waktu tunggu dalam interval kecil, misalnya setengah jam, dan skrip untuk melakukannya ada di sini.
Anda juga bisa mendapatkan statistik menunggu menggunakan add-in Server Reports ke alat Azure Data Studio yang baru, dan menggunakan Query Store dari SQL Server 2017 dan seterusnya.
Ingat, Anda masih perlu memahami apa arti jenis menunggu setelah Anda mengumpulkan metrik.
Menunggu Sumber Daya
Untuk membantu dengan ini, dan karena Microsoft tidak memiliki dokumentasi tentang cara menafsirkan statistik menunggu, pada tahun 2016 saya merilis perpustakaan tipe tunggu, dengan rincian ratusan tipe tunggu umum dan cara memecahkan masalah mereka. Anda bisa mendapatkan ke perpustakaan di https://www.SQLskills.com/help/waits. Dan kemudian pada tahun 2017, SentryOne membuat sistem otomatis untuk menyediakan infografis untuk setiap halaman di perpustakaan yang dapat Anda gunakan dengan cepat untuk melihat apakah jenis tunggu yang Anda minati benar-benar umum atau tidak (lihat posting ini untuk detailnya) . Contoh infografis di bawah ini, untuk PAGEIOLATCH_SH jenis tunggu:
Pada sumbu horizontal adalah skala (dapat dialihkan antara linier dan logaritmik) dari berapa persentase instans (dipantau dari jarak jauh oleh SentryOne) yang mengalami penantian ini selama bulan kalender sebelumnya, dan pada sumbu vertikal adalah persentase waktu instans yang mengalami itu tunggu sebenarnya memiliki utas yang menunggu untuk jenis menunggu itu.
Satu sumber lain untuk membantu Anda memahami menunggu adalah kursus pelatihan online yang saya rekam untuk Pluralsight – lihat di sini.
Paling tidak, Anda harus membaca berbagai posting blog di bagian Statistik Tunggu dan Pelacakan Menunggu di atas.
Melacak Waktu Tunggu Menggunakan Alat SentryOne
SQL Sentry melacak tingkat instans menunggu Anda secara otomatis dari waktu ke waktu, jadi Anda tidak perlu menunggu terlalu lama "dalam tindakan". Seseorang mengeluh tentang sistem yang lamban kemarin sore atau laporan yang habis waktu Selasa lalu? Tidak masalah. Anda dapat menggali semua penantian untuk titik waktu mana pun atau dalam rentang waktu tertentu, dan menghubungkannya dengan berbagai metrik kinerja lain yang dikumpulkan pada saat itu – baik itu tren lain di dasbor, seperti pencadangan atau aktivitas I/O basis data, melompat ke semua perintah SQL Teratas yang berjalan di jendela yang sama, menyelidiki pemblokiran yang berjalan lama, atau menggunakan garis dasar untuk membandingkan profil menunggu dengan periode lain.
Anda bahkan dapat menyesuaikan waktu tunggu yang dikumpulkan atau tidak, mengubah kategori yang disajikan secara visual, dan membangun peringatan dan/atau tanggapan cerdas untuk skenario menunggu tertentu. Banyak pelanggan kami menggunakan SQL Sentry untuk fokus pada masalah kinerja nyata yang berkaitan dengan menunggu, karena memungkinkan mereka untuk mengabaikan banyak kebisingan yang merupakan aktivitas utas SQL Server biasa.
Ringkasan
Seperti yang Anda lihat dari informasi di atas, menunggu selalu terjadi di SQL Server, karena begitulah cara kerja penjadwalan thread dan sistem multi-utas. Mereka adalah salah satu alat paling kuat di kotak alat pemecahan masalah Anda, jadi jika Anda belum menggunakannya, sekaranglah saatnya untuk memulai. Kurva pembelajarannya pendek dan curam – setelah Anda menjalankan berbagai kueri dan alat beberapa kali, Anda akan segera menguasainya, dan kemudian ini adalah kasus membaca panduan untuk penantian yang Anda lihat dan menentukan apakah itu masalah tidak.
Selamat memecahkan masalah!
