Dalam posting ini saya akan membahas metodologi umum untuk mengatasi masalah kinerja CPU. Saya suka menerapkan metodologi secara default dan saya juga suka membangun efisiensi dalam cara saya memecahkan masalah berdasarkan pengalaman masa lalu. Tanpa kerangka umum, menjadi terlalu mudah untuk melewatkan akar penyebab sebenarnya di tengah krisis.
Langkah-langkah yang akan saya jelaskan di postingan ini adalah sebagai berikut:
- Tentukan masalahnya
- Validasi kondisi saat ini
- Jawab “Apakah itu SQL Server”?
- Identifikasi konsumen CPU
- Cocokkan polanya dan selesaikan
Artikel ini akan membahas masing-masing langkah tersebut. Saya akan membuat asumsi bahwa Anda mungkin tidak menggunakan alat pemantauan pihak ketiga. Jika ya, kerangka kerja di sini masih berlaku, tetapi sumber data dan alat yang Anda gunakan akan berbeda dari yang saya jelaskan.
Tentukan masalahnya
Pertama kita perlu melingkupi masalah. Ketika seseorang mendatangi Anda dan mengatakan mereka melihat masalah kinerja CPU, ini bisa berarti sejumlah hal yang berbeda. Jadi tugas pertama adalah memahami sifat masalah kinerja CPU saat ini.
Beberapa kategori umum meliputi:
- Ketersediaan terpengaruh karena "CPU yang dipatok". Misalnya – semua penjadwal berjalan 100% secara menyeluruh dan throughput terhenti atau berkurang secara signifikan.
- Penurunan kinerja karena penggunaan CPU "lebih tinggi dari biasanya". Jadi kami tidak dipatok, tetapi CPU Anda berjalan pada persentase yang lebih tinggi dari biasanya dan mungkin memengaruhi kinerja.
- Kategori umum lainnya dari masalah kinerja CPU adalah skenario "pemenang dan pecundang" di mana beban kerja bersaing satu sama lain. Mungkin Anda memiliki beban kerja OLTP yang mengalami penurunan throughput karena kueri laporan yang dijalankan secara paralel.
- Masalah lain mungkin menemui titik kritis – di mana kapasitas keseluruhan dan batasan skalabilitas sistem Anda mencapai titik tertentu.
Saya menyebutkan kategori-kategori yang berlebihan ini sebagai titik awal, tetapi saya tahu bahwa seringkali ada ketergantungan yang besar pada masalah-masalah ini dan satu kategorisasi dapat berbaur dengan yang lain. Dengan demikian, langkah pertama adalah mendefinisikan gejala dan masalah sejelas mungkin.
Validasi kondisi saat ini
Apakah masalah terjadi di masa lalu atau sedang terjadi saat ini, penting untuk mendapatkan informasi latar belakang sebanyak mungkin tentang sistem, beban kerja, dan konfigurasi. Jika Anda menggunakan baseline dan run-book, idealnya Anda sudah melacak banyak informasi ini. Jika tidak, tanyakan pada diri Anda seberapa cepat Anda bisa mendapatkan jawaban atas pertanyaan-pertanyaan ini pada pukul 02.00 di tengah krisis.
Sub-bagian berikut mencakup poin data penting yang biasanya saya minati untuk masalah kinerja CPU.
- Berapa banyak socket dan core?
- Apakah hyper-threading diaktifkan?
- Apa model prosesor, arsitektur (32-bit/64-bit)?
- Apakah ini tamu virtual?
- Jika demikian, Anda sekarang juga akan tertarik dengan detail tentang tuan rumah dan tamu virtual lain yang Anda ajak berbagi sumber daya.
- Apakah ada pengaturan terkait CPU yang berlaku?
- Misalnya, CPU Hyper-V
- Berapa banyak vCPU yang dialokasikan untuk semua tamu?
- Berapa banyak vCPU yang dimiliki tamu ini?
- Apakah tamu baru saja bermigrasi ke host baru sebelum masalah ini terjadi?
- Setelan derajat paralelisme maksimum
- Ambang biaya untuk opsi paralelisme
- Pengaturan afinitas prosesor
- Setelan peningkatan prioritas
- Setelan utas pekerja maksimum
- Pengaturan penggabungan yang ringan
- Apa pengaturan opsi daya? (Tingkat OS, Host VM, atau dikontrol BIOS)
- Kinerja Tinggi, Seimbang, Hemat Daya?
- Apakah dikonfigurasi di luar pengaturan default?
- Apakah Anda melihat peringatan atau kesalahan yang tidak biasa?
Detail server fisik
Detail server virtual
Cadangan, Reservasi CPU VMware, Berat Relatif CPU Hyper-V, dan Pembagian CPU VMware.
Pengaturan konfigurasi instans SQL Server
Tiga konfigurasi pertama mungkin memerlukan diskusi lebih lanjut. Jarang ada yang mutlak mengenai pengaturan ini.
Mengenai tiga pengaturan terakhir, seperti "peningkatan prioritas", jika saya melihat bahwa mereka berada pada nilai non-default, saya pasti akan mendorong lebih banyak informasi latar belakang dan riwayat.
Setelan opsi daya CPU
Setelan opsi daya di bawah “Kinerja Tinggi” masih sangat umum dan tidak boleh diabaikan untuk server yang menghosting instans SQL Server.
Konfigurasi Gubernur Sumber Daya
Saya masih merasa jarang menemukan pelanggan yang menggunakan fitur ini sama sekali, tetapi mudah untuk memvalidasi apakah fitur ini sedang digunakan dan akan bermanfaat untuk waktu yang sebenarnya dikonfigurasi di luar default.
Log kesalahan SQL Server dan log peristiwa Windows
Mengapa mencari kesalahan dan log peristiwa untuk masalah CPU? Terkadang masalah hulu dapat menyebabkan masalah kinerja hilir di SQL Server. Anda tidak ingin membuang waktu untuk menyetel kueri atau menambahkan indeks baru saat Anda mengetahui akar masalah upstream adalah masalah degradasi komponen perangkat keras.
Jawab “Apakah itu SQL Server?”
Kedengarannya jelas ketika saya menanyakannya, tetapi Anda benar-benar tidak ingin menghabiskan banyak waktu untuk memecahkan masalah CPU yang tinggi di SQL Server jika pelakunya sebenarnya bukan SQL Server.
Alih-alih, luangkan waktu sejenak untuk memeriksa proses mana yang memakan CPU paling banyak. Ada beberapa opsi yang dapat dipilih, antara lain:
- Proses:% Waktu Pengguna (mode pengguna)
- Proses:% Waktu Istimewa (mode kernel)
- Manajer Tugas
- Penjelajah Proses
- Informasi CPU terbaru melalui sys.dm_os_ring_buffers atau sesi kondisi sistem untuk instance SQL Server tertentu yang berjalan di sistem
Jika SQL Server dan Anda memiliki beberapa contoh SQL Server untuk dipilih, pastikan Anda memecahkan masalah contoh SQL Server yang tepat di host. Ada beberapa cara untuk melakukannya, termasuk penggunaan SELECT SERVERPROPERTY('processid') untuk mendapatkan PID dan kemudian mengaitkannya ke Pengelola Tugas atau Penjelajah Proses.
Setelah Anda mengonfirmasi bahwa itu adalah SQL Server, apakah Anda melihat waktu pengguna yang tinggi atau waktu istimewa (kernel)? Sekali lagi ini dapat dikonfirmasi melalui Process:% Privileged Time (objek sqlservr) dan juga Windows Task Manager atau Process Explorer.
Meskipun masalah waktu kernel yang tinggi seharusnya jarang terjadi, mereka masih memerlukan jalur pemecahan masalah yang berbeda dari masalah pemecahan masalah CPU waktu pengguna standar. Beberapa penyebab potensial dari waktu kernel yang tinggi termasuk driver filter yang salah (anti-virus, layanan enkripsi), pembaruan dan driver firmware yang kedaluwarsa atau hilang, atau komponen I/O yang rusak.
Identifikasi konsumen CPU
Setelah Anda memvalidasi instance SQL Server mana yang mendorong penggunaan CPU waktu pengguna pada sistem, ada banyak contoh kueri pra-kalengan di web yang dapat Anda gunakan.
Di bawah ini adalah daftar DMV yang biasanya digunakan orang dalam berbagai bentuk selama masalah kinerja. Saya menyusun ini dalam format Tanya Jawab untuk membantu membingkai mengapa Anda ingin mengaksesnya.
- sys.dm_exec_requests
- sys.dm_exec_sql_text
- sys.dm_exec_sessions
- sys.dm_exec_connections
- sys.dm_exec_query_plan
- sys.dm_os_waiting_tasks
- sys.dm_exec_query_stats
- Agregat menurut total_worker_time
- Tentukan rata-rata dengan execution_count
- Jika beban kerja ad hoc, Anda dapat mengelompokkan menurut query_hash
- Gunakan plan_handle dengan sys.dm_exec_query_plan untuk mengambil paket
- sys.dm_os_tasks
- Diurutkan berdasarkan session_id, request_id
- sys.dm_exec_query_plan
- Lihat operator paket – namun perlu diingat ini hanya perkiraan paket
- sys.dm_exec_query_stats
- Filter total_elapsed_time kurang dari total_worker_time
- Tetapi perhatikan bahwa ini bisa menjadi negatif palsu untuk skenario pemblokiran – di mana durasi meningkat karena menunggu sumber daya
Permintaan apa yang sedang dijalankan saat ini dan apa statusnya?
Apa yang dijalankannya?
Dari mana asalnya?
Berapa perkiraan rencananya? (tapi hati-hati untuk merobek-robek xml pada sistem yang sudah dibatasi CPU)
Siapa yang menunggu sumber daya dan apa yang mereka tunggu?
Kueri mana yang paling banyak menghabiskan waktu CPU sejak restart terakhir?
Apakah kueri ini menggunakan paralelisme?
Cocokkan polanya dan selesaikan
Anda mungkin menertawakan langkah khusus ini – karena langkah ini bisa menjadi yang paling terlibat (dan merupakan alasan lain mengapa profesional SQL Server dipekerjakan dengan baik). Ada beberapa pola berbeda dan resolusi terkait – jadi saya akan menyelesaikan posting ini dengan daftar driver masalah kinerja CPU yang lebih umum yang saya lihat selama beberapa tahun terakhir:
- Operasi I/O tinggi (dan menurut pengalaman saya ini adalah driver CPU yang paling umum)
- Masalah perkiraan kardinalitas (dan kualitas paket kueri terkait yang buruk)
- Paralelisme tak terduga
- Kompilasi/kompilasi ulang yang berlebihan
- Panggilan UDF dengan perhitungan intensif, operasi penghancuran
- Operasi baris yang menyiksa
- Aktivitas pemeliharaan bersamaan (mis. UPDATE stats dengan FULLSCAN)
Setiap area yang saya identifikasi memiliki banyak pekerjaan terkait untuk diteliti. Dalam hal sumber daya terkonsolidasi, saya masih berpikir salah satu yang lebih baik adalah artikel teknis “Pemecahan Masalah Kinerja di SQL Server 2008” yang ditulis oleh Sunil Agarwal, Boris Baryshnikov, Keith Elmore, Juergen Thomas, Kun Cheng dan Burzin Patel.
Ringkasan
Seperti halnya metodologi apa pun, ada batasan untuk pemanfaatannya dan area di mana Anda dibenarkan dalam berimprovisasi. Harap dicatat bahwa saya tidak menyarankan langkah-langkah yang saya jelaskan dalam posting ini digunakan sebagai kerangka kerja yang kaku, tetapi menganggapnya sebagai titik peluncuran untuk upaya pemecahan masalah Anda. Bahkan profesional SQL Server yang sangat berpengalaman dapat membuat kesalahan pemula atau bias oleh pengalaman pemecahan masalah mereka yang lebih baru, sehingga memiliki metodologi minimal dapat membantu menghindari pemecahan masalah yang salah.
