Jika pengguna database Anda mengeluh bahwa kinerja SQL Server akhir-akhir ini tidak bagus, mungkin Anda mengalami efek dari satu atau lebih kemacetan SQL Server. Kemacetan ini terjadi karena berbagai alasan, tetapi sering terjadi sebagai akibat dari masalah dengan memori, I/O, atau CPU.
Meskipun tidak selalu mudah untuk menentukan apakah masalah kinerja berasal dari hambatan SQL Server atau dari sumber lain, Anda dapat mencari gejala umum hambatan ini untuk membantu mempersempit pencarian sumber masalah.
Gejala Umum dari Kemacetan SQL Server
- SQL Server memonopoli prosesor
- Waktu eksekusi lebih lama pada kueri
- I/O yang berlebihan
- Log aplikasi menampilkan pesan kehabisan memori
- Aktivitas ekstrem pada disk
- Waktu tunggu yang lama per I/O
Munculnya satu atau lebih gejala ini secara tiba-tiba merupakan indikasi yang baik bahwa Anda memiliki hambatan SQL Server di suatu tempat di sistem Anda. Sekarang, tugas Anda untuk menemukannya.
Jenis Hambatan SQL Server
Ada tiga jenis utama kemacetan SQL Server:memori, I/O, dan CPU. Penting bagi DBA untuk memahami penyebab, gejala, dan perbaikan masing-masing sehingga mereka dapat mengidentifikasi dan menghilangkan hambatan dengan cepat dan meminimalkan dampak kinerja yang buruk. Kami juga menyertakan beberapa penghitung kinerja terbaik untuk dipantau yang akan membantu mengidentifikasi kemacetan kinerja dengan segera.
Kemacetan Memori
Kemacetan memori biasanya merupakan akibat dari sumber daya memori yang tidak mencukupi atau aktivitas SQL Server memakan memori yang tersedia. Gejala yang harus diwaspadai termasuk waktu eksekusi kueri yang lebih lama, I/O yang berlebihan, pesan kehabisan memori di log aplikasi, dan seringnya sistem mogok.
Cara terbaik untuk menghindari kemacetan terkait memori adalah dengan menggunakan pengoptimal kueri untuk menyingkirkan kueri yang tidak perlu atau usang dan mengonfigurasi harapan hidup halaman bersama dengan rasio hit cache buffer untuk membatasi perjalanan ke disk. Jika sudah terlambat untuk menghindari kemacetan, coba tinjau dan sesuaikan kueri, konfigurasi ulang memori, atau tambahkan memori fisik.
Penghitung untuk dipantau:memori yang tersedia, total memori server, memori server target, halaman/dtk, rasio hit cache buffer
Kemacetan I/O
Ketika tidak ada cukup penyimpanan yang tersedia untuk mendukung operasi database reguler seperti TempDB, kemacetan I/O kemungkinan akan terjadi. Waktu respons yang lama, pelambatan aplikasi, dan waktu habis tugas yang sering merupakan indikator utama bahwa Anda memiliki hambatan I/O.
Anda dapat menghindari jenis kemacetan ini dengan menyiapkan pemantauan dengan alarm dan peringatan ambang batas untuk mengidentifikasi aktivitas mana yang menggunakan penyimpanan dalam jumlah berlebihan. Jika terjadi kemacetan I/O, batasi membaca dan menulis halaman database ke dan dari disk. Ini akan mengharuskan Anda untuk memeriksa dan memperbaiki pemindaian indeks yang sering, kueri yang tidak efisien, dan statistik yang kedaluwarsa.
Penghitung untuk dipantau:rata-rata panjang antrian disk, rata-rata dtk/baca disk, rata-rata dtk/tulis disk, % waktu disk, rata-rata pembacaan/dtk disk, rata-rata penulisan disk/dtk
Kemacetan CPU
Penyebab utama kemacetan CPU adalah sumber daya perangkat keras yang tidak mencukupi. Cukup mudah untuk mengidentifikasi hambatan ini dengan memeriksa log Anda untuk menentukan apakah SQL Server menggunakan CPU yang berlebihan.
Di dunia yang ideal, Anda dapat menghindari kemacetan CPU dengan memiliki server khusus SQL Server dan menjalankan semua perangkat lunak lain di komputer lain. Karena itu bukan opsi untuk sebagian besar DBA, Anda perlu tahu cara menghilangkan hambatan CPU Anda.
Langkah pertama adalah mengidentifikasi CPU hog. Setelah Anda mengetahui di mana letak masalahnya, Anda dapat menyesuaikan kueri, meningkatkan rencana eksekusi Anda, atau mengonfigurasi ulang sistem.
Penghitung untuk dipantau:% waktu prosesor, permintaan batch/dtk, kompilasi SQL/dtk, kompilasi ulang SQL/dtk
Kisah tentang Kemacetan Kinerja SQL Server
“Kami memiliki beberapa hambatan kinerja SQL Server yang harus ditangani,” kata bos saya, pada suatu Jumat larut malam.
"Bagaimana Anda tahu?" saya bertanya.
“Penjualan mengeluh bahwa database mereka telah melambat akhir-akhir ini. Kita perlu melihat apa yang terjadi dengannya.”
"OKE. Saya akan memesan ruang konferensi sehingga kita bisa duduk dan mengerjakannya.”
"Jangan repot-repot," kata bos. “Ini sudah larut pada hari Jumat sore. Itu berarti bahwa cara terbaik untuk mempelajari kemacetan adalah dengan pasangan kita sendiri. Kami akan pergi ke Pike Pub di pasar.”
Kami berjalan ke bar yang terletak di Pike Place Market dan menemukan meja kecil di dekat jendela.
“Apa jenis kemacetan favorit Anda?” tanya bos.
Saya katakan saya tidak menyukai Naughty Nellie dalam kemacetan 22 ons.
"Pilihan yang bagus," kata bos. “Anda yang memesannya, dan saya akan memesan Citrus Summer Ale.”
Sementara kami menunggu kemacetan kami tiba, kami turun ke bisnis di kemacetan kinerja SQL Server.
"Kita perlu memeriksa masalah di beberapa tempat," kata bos. “Bisa jadi masalah dengan memori, penyimpanan, atau prosesor, tetapi semuanya terlihat hampir sama bagi pengguna, bukan? Performa payah.
“Masalah CPU tidak terlalu sulit ditemukan. Jika itu masalahnya, maka kita akan melihat bahwa SQL Server memonopoli prosesor dan menyebabkannya melonjak sepanjang waktu.
“Jika ini masalah memori, kita akan melihat hal-hal seperti waktu eksekusi yang lebih lama pada kueri dan lebih banyak I/O karena aplikasi harus terus kehabisan disk. Kami juga dapat memeriksa log aplikasi untuk pesan kehabisan memori.
“Dan jika kemacetan terjadi di penyimpanan, kita akan melihat aktivitas ekstrem pada disk dan waktu tunggu yang lama per I/O.”
Kemacetan kami tiba. Kami mempelajarinya dengan cermat saat kami mempertimbangkan masalah kinerja lebih dalam.
Banyak Sumber Potensi Kemacetan Kinerja SQL Server
“Bagaimana jika itu adalah masalah I/O?” Saya bertanya. “Kita harus melihat apakah waktu tunggu WRITELOG terlalu tinggi, dibandingkan dengan waktu tunggu total. Atau, berbicara tentang I/O, mungkin ada masalah di SQL itu sendiri. Jika ada kode yang tidak efisien, seperti NESTED LOOP JOIN pada tabel besar, SQL dapat meminta untuk membaca baris di tabel dalam jutaan kali. Itu benar-benar akan menghukum kinerja.”
"Bisa jadi," kata bos. “Operasi penggabungan dan penyortiran yang rumit bisa jadi sulit, terutama ketika database tempdb tidak dikonfigurasi dengan benar. Pertentangan Tempdb terlihat seperti kunci basis data biasa, tetapi sebenarnya adalah pertikaian yang terkunci karena proses bersamaan semua menunggu giliran pada halaman alokasi.”
“Alat apa yang bisa kita gunakan untuk memeriksa semua ini?” saya bertanya.
“SQL Server memiliki profiler untuk memeriksa prosedur tersimpan, tetapi sudah usang. Sesuatu seperti itu adalah cara yang baik untuk menemukan dan mendiagnosis pertanyaan masalah, meskipun itu hanya langkah pertama. Lalu ada tampilan dan fungsi manajemen dinamis yang membantu Anda memantau kesehatan server dan database Anda, mengatasi masalah, dan menyempurnakan SQL Anda.”
“Tetapi SQL Server memiliki begitu banyak bagian yang bergerak,” kata saya. “Saya lebih suka memiliki alat yang melihat keseluruhan gambar dari luar ke dalam.”
“Saya juga. Lebih disukai dari cloud, jadi kami tidak memerlukan lebih banyak perangkat keras dan perangkat lunak di tempat untuk melakukannya.”
Menghilangkan Kemacetan Kinerja di SQL Server
Pike mulai ramai. Dan, seperti halnya bos dan saya yang ingin duduk di pub dan toko bincang-bincang, bagaimanapun juga, itu adalah Jumat malam. Kami memiliki tempat lain untuk dikunjungi, orang lain untuk dilihat, dan hal lain untuk dibicarakan.
“Apa yang harus kita lakukan setelah kita menemukan kemacetan?” saya bertanya.
"Kami menangkap tersangka yang biasa," kata bos. “Agar tidak menggunakan terlalu banyak memori, kami perlu memberi tahu pengembang basis data kode dan kueri mana yang membocorkan memori. Jika kami menemukan operasi yang menggabungkan empat, lima atau enam tabel, kami harus memberi pengembang beberapa kiat penyetelan SQL Server dan praktik terbaik untuk mendesain ulang database. Atau, kami mungkin memiliki terlalu banyak indeks dan kami mungkin membuang-buang waktu untuk memperbaruinya; itu sama sulitnya dengan CPU dan I/O karena memiliki terlalu sedikit indeks. Kami mungkin memiliki masalah dengan fragmentasi indeks SQL Server, atau kami mungkin harus menyingkirkan indeks yang usang dan terduplikasi.”
"Masuk akal," kataku. “Mungkin kita perlu mengeluarkan lebih banyak perangkat keras untuk itu. Disk yang lebih cepat dapat membantu mengatasi kemacetan I/O. CPU yang lebih banyak dan lebih cepat membuat perbedaan dalam waktu respons kueri. Dan menambahkan RAM berarti lebih banyak skalabilitas SQL Server, bukan?”
“Ya,” kata bosnya, “tetapi pertama-tama saya ingin memastikan bahwa akar masalahnya bukanlah masalah pengembangan atau DevOps. Setelah saya yakin tidak, saya akan memainkan kartu Beli Lebih Banyak Perangkat Keras.”
Kami duduk sejenak dan menyaksikan pub penuh dengan orang-orang yang bersuka ria pada Jumat malam.
“Bos,” saya bertanya, “apa menurut Anda semua orang ini tahu betapa riangnya kehidupan yang mereka jalani, tanpa beban berurusan dengan sesi yang diblokir, tunggu I/O maksimum, harapan hidup halaman, dan rasio hit cache buffer?”
“Ini adalah salib yang harus dipikul, bukan?” jawab bos. “Kebanyakan orang tidak tahu apa yang kita alami. Untung kami menangani kemacetan kinerja SQL Server dengan sangat tenang, dengan begitu banyak rahmat di bawah tekanan dan dengan selera yang baik. Berbicara tentang selera yang baik, bagaimana kabarmu di kemacetanmu?”
saya memeriksa. “Keterlambatan saya kosong. Begitu juga dengan botol saya.”
“Milikku juga. Waktu untuk pergi. Kami punya pekerjaan yang harus dilakukan.”
Apakah Sistem Bottleneck Nol SQL Server Mungkin?
Kami tahu ada langkah-langkah yang dapat kami ambil untuk menghindari ketiga jenis kemacetan SQL Server yang umum ini. Tetapi apakah mungkin untuk mengonfigurasi database SQL Server dengan baik sehingga tidak ada hambatan?
Jawaban singkatnya mungkin tidak. Bahkan DBA yang paling rajin sekalipun akan mengalami kemacetan SQL Server sesekali. Tetapi Anda dapat mengambil langkah-langkah untuk secara proaktif menghindari kemacetan dan meminimalkan dampaknya terhadap kinerja. Misalnya, Brent Ozar menawarkan beberapa kiat hebat untuk memantau penghitung Perfmon untuk menyempurnakan SQL Server Anda, dan Anda dapat menggunakan tampilan sys.dm_os_performance_counters untuk membantu mengidentifikasi kemacetan dan memperbaikinya dengan cepat.
Kemacetan SQL Server adalah fakta kehidupan DBA. Untungnya, dengan pengawasan yang memadai, pemantauan yang cermat, dan penyetelan kueri yang sering, masalah kinerja dapat ditangani bahkan sebelum pengguna mengetahui ada masalah.
