Pemecahan masalah kinerja adalah seni dan ilmu. Seni berasal dari pengalaman (dan belajar dari pengalaman orang lain) dan sains berasal dari pedoman terkenal tentang apa yang harus dilakukan dalam skenario apa.
Atau setidaknya itulah yang saya suka pikirkan, dan ajarkan.
Pada kenyataannya, banyak DBA dan pengembang di luar sana mempraktikkan apa yang saya sebut 'pemecahan masalah kinerja spontan. Ini biasanya terjadi ketika masalah kinerja telah mencapai tahap kritis dengan, misalnya, waktu kueri habis, proses berjalan lambat atau gagal, pengguna tidak puas, dan manajemen menginginkan jawaban dan tindakan cepat!
The 'knee-jerk' berasal dari melakukan beberapa analisis dangkal dari masalah dan melompat ke kesimpulan (benar-benar itu menggenggam sedotan) bahwa gejala yang paling umum harus menjadi akar penyebab dan mencoba untuk mengatasinya, tanpa atau sedikit berhasil, sering menggunakan saran yang salah arah atau benar-benar salah yang ditemukan secara online. Hal ini menyebabkan banyak frustrasi dan waktu yang terbuang, dan sering menyebabkan pemborosan uang ketika organisasi memutuskan untuk mencoba membuang perangkat keras pada masalah dengan memutakhirkan server dan/atau subsistem I/O, hanya untuk menemukan masalah masih ada , atau muncul kembali cukup cepat lagi.
Analisis statistik menunggu adalah salah satu area yang paling mudah untuk dilakukan, dan dalam posting ini saya akan berbicara tentang beberapa jenis menunggu yang umum dan kesalahan yang dilakukan orang di sekitarnya. Tidak ada ruang lingkup dalam artikel seperti ini untuk membahas secara mendalam tentang apa yang harus dilakukan dalam setiap kasus, tetapi saya akan memberi Anda informasi yang cukup untuk mengarahkan Anda ke arah yang benar.
LCK_M_XX
Kebanyakan orang berasumsi bahwa jika penguncian menunggu adalah yang paling umum, maka itu pasti semacam masalah pemblokiran yang menjadi masalah. Seringkali, seperti kurangnya indeks nonclustered yang sesuai menyebabkan pemindaian tabel di tingkat isolasi REPEATABLE_READ atau SERIALIZABLE yang meningkat ke kunci tabel S. (Dan sebagai petunjuk cepat, jika Anda merasa tidak pernah menggunakan SERIALIZABLE, Anda melakukannya jika Anda menggunakan transaksi terdistribusi – semuanya diubah menjadi SERIALIZABLE di bawah selimut, yang dapat menyebabkan pemblokiran dan kebuntuan yang tidak terduga.)
Namun, sering kali pemblokiran disebabkan oleh hal lain. Di bawah tingkat isolasi READ_COMMITTED default, kunci yang mencakup perubahan ditahan hingga transaksi dilakukan, dan akan memblokir pembacaan dan pembaruan lainnya ke baris yang sama. Jika ada sesuatu yang mencegah transaksi dilakukan, itu dapat menyebabkan pemblokiran muncul.
Misalnya, jika database dicerminkan secara sinkron, maka transaksi tidak dapat melakukan dan melepaskan kuncinya sampai catatan log telah dikirim ke cermin dan ditulis ke drive log cermin. Jika jaringan sangat padat, atau ada pertentangan I/O besar-besaran di mirror, ini dapat secara serius menunda operasi mirroring, dan dengan demikian menyebabkan transaksi membutuhkan waktu lebih lama untuk dilakukan. Ini akan terlihat seperti pemblokiran tetapi akar masalahnya adalah perebutan sumber daya yang berkaitan dengan pencerminan.
Untuk mengunci menunggu, kecuali penyebabnya jelas dari melihat rencana kueri, mengunci sumber daya (misalnya tingkat tabel yang menunjukkan eskalasi penguncian, atau tingkat isolasi, ikuti rantai pemblokiran (menggunakan skrip yang berjalan di kolom blocking_session_id di sys.dm_exec_requests dan kemudian lihat untuk melihat apa yang ditunggu oleh utas di kepala rantai pemblokiran. Itu akan mengarah ke akar masalahnya.
ASYNC_NETWORK_IO
Nama yang satu ini menyebabkan banyak kebingungan. Kata apa yang Anda fokuskan? JARINGAN. Penyebab tipe wait ini biasanya tidak ada hubungannya dengan jaringan. Itu harus benar-benar disebut WAITING_FOR_APP_ACK (pengetahuan), atau sesuatu yang serupa, karena itulah yang terjadi:SQL Server telah mengirim beberapa data ke klien dan menunggu klien untuk mengakui bahwa telah mengkonsumsi data.
Salah satu demo favorit saya untuk dilakukan ketika mengajar tentang statistik tunggu adalah dengan menjalankan kueri yang mengembalikan sejumlah besar hasil di Management Studio dan melihat server mengumpulkan ASYNC_NETWORK_IO menunggu. Jelas tidak ada jaringan yang terlibat – hanya SSMS yang membutuhkan waktu lama untuk membalas SQL Server. Itu melakukan apa yang dikenal sebagai RBAR (Row-By-Agonizing-Row), di mana hanya satu baris pada satu waktu yang ditarik dari hasil dan diproses, alih-alih menyimpan semua hasil dan kemudian segera membalas SQL Server dan melanjutkan untuk memproses baris yang di-cache.
Ini adalah penyebab utama ASYNC_NETWORK_IO menunggu – desain aplikasi yang buruk. Saya kemudian akan melihat apakah server yang menjalankan kode aplikasi memiliki masalah kinerja, bahkan jika kode aplikasi itu sendiri dirancang dengan baik. Kadang-kadang karena jaringan, tetapi menurut pengalaman saya, itu jarang terjadi.
OLEDB
Reaksi spontan yang umum di sini adalah menyamakan tipe menunggu ini dengan server yang ditautkan. Namun, waktu tunggu ini menjadi lebih umum untuk dilihat ketika SQL Server 2005 dikirimkan, karena 2005 berisi sejumlah DMV baru, dan sebagian besar DMV menggunakan OLE DB di bawah penutup. Sebelum mencari masalah server tertaut, saya akan memeriksa apakah alat pemantauan menjalankan DMV terus-menerus di server.
Jika Anda memiliki server tertaut, lanjutkan pemecahan masalah dengan membuka server tertaut dan melihat statistik tunggu di sana untuk melihat masalah yang paling umum, lalu lanjutkan analisis yang sama.
Satu hal lain yang dapat menyebabkan OLEDB menunggu adalah DBCC CHECKDB (dan perintah terkait). Ini menggunakan rowset OLE DB untuk mengkomunikasikan informasi antara Query Processor dan subsistem Storage Engine.
Penantian Lainnya
Beberapa penantian lain yang menyebabkan reaksi spontan adalah CXPACKET, PAGEIOLATCH_XX, SOS_SCHEDULER_YIELD, dan WRITELOG, dan saya akan membahasnya di posting saya bulan depan.
Ringkasan
Saat Anda memiliki masalah kinerja, luangkan waktu untuk memahami data yang Anda lihat dan lakukan penyelidikan lebih lanjut untuk membantu mempersempit akar penyebab masalah. Jangan hanya memahami apa pun yang tampaknya menjadi statistik tunggu teratas dan ikuti saran pertama yang Anda temukan online (kecuali jika itu dari sumber yang terkenal dan bereputasi baik) atau Anda mungkin tidak akan menyelesaikan masalah Anda, dan bahkan mungkin memperburuknya.
Sejauh menyangkut statistik tunggu umum, Anda dapat menemukan informasi lebih lanjut tentang menggunakannya untuk pemecahan masalah kinerja di:
- Seri posting blog saya, dimulai dengan statistik Tunggu, atau tolong beri tahu saya di bagian mana yang sakit
- Perpustakaan Jenis Tunggu dan Kelas Latch Saya di sini
- Kursus pelatihan online Pluralsight saya SQL Server:Pemecahan Masalah Kinerja Menggunakan Statistik Tunggu
- Penasihat Kinerja SQL Sentry
Ini adalah yang pertama dari serangkaian posting yang akan saya lakukan selama tahun ini yang berbicara tentang tindakan spontan (kembali) di sekitar SQL Server dan mengapa mereka melakukan hal yang salah. Sampai jumpa lagi, selamat memecahkan masalah!
