Brent Ozar, Master Bersertifikat Microsoft baru-baru ini membahas paralelisme di SQL Server, khususnya jenis tunggu CXPACKET dan CXCONSUMER dalam angsuran terakhirnya dari Seri Musim Gugur Pelatihan Database Quest. Dengan gayanya yang lucu dan mudah diakses, Brent mengungkap konsep paralelisme dan menjelaskan cara menanganinya saat Anda melihat terlalu banyak statistik menunggu CXPACKET dan CXCONSUMER.
Pertama, apa itu paralelisme, dan mengapa SQL Server membuat kueri dieksekusi secara paralel?
Sederhananya, SQL Server secara otomatis mengenali bahwa permintaan tertentu memiliki beban kerja yang besar, dan menentukan bahwa pekerjaan dapat dilakukan lebih efisien di beberapa prosesor daripada hanya dengan satu. Ini umumnya merupakan keputusan yang cerdas, tetapi dapat mengalami masalah saat SQL Server tidak menyeimbangkan beban di seluruh utas yang melakukan tugas.
Memahami jenis tunggu CXPACKET dan CXCONSUMER
CXPACKET dan CXCONSUMER adalah tipe menunggu yang menunjukkan bahwa pekerjaan tidak seimbang. Saat Anda melihat statistik tunggu ini di server Anda, Anda akan tahu bahwa SQL Server menjalankan kueri secara paralel, tetapi tidak melakukan pekerjaan yang baik untuk mendistribusikannya ke seluruh prosesor yang tersedia.
Setiap profesional basis data akrab dengan konsep "biaya" untuk mengungkapkan betapa mahalnya permintaan untuk dieksekusi dalam hal konsumsi sumber daya. "Dolar kueri" ini adalah ukuran perkiraan pekerjaan, dan sinyal penting apakah kueri akan berjalan secara paralel atau tidak. Kueri yang murah tidak perlu dijalankan secara paralel, tetapi kueri yang mahal akan melakukannya. Tujuannya adalah untuk mengeksekusi kueri secepat dan seefisien mungkin sehingga yang berikutnya dalam antrean dapat dimulai. SQL Server menetapkan utas sebagai penjadwal, dan utas ini, yang dianggap Brent sebagai "robot overlord", akan menetapkan bagian dari beban kerja paralel ke utas pekerja, atau "robot minion".
Paralelisme dan penguasa robot
Brent terjun ke demo untuk menunjukkan cara kerjanya. Menggunakan database Stack Overflow, ia membuat pencarian database murah yang sangat cepat karena adanya indeks. Rencana eksekusi cukup mudah dan tidak memerlukan paralelisme untuk dijalankan.
Namun, saat dia memperkenalkan pencarian untuk sesuatu yang tidak ada dalam indeks, banyak hal berubah dengan memaksa pencarian kunci untuk setiap baris pada indeks cluster tabel. SQL Server menyadari ini akan banyak pekerjaan, sehingga memperkenalkan paralelisme dan ditunjukkan seperti itu dengan ikon pada rencana eksekusi. Jika rencana eksekusi adalah tiga dimensi, Anda akan dapat melihat beberapa utas ditumpuk, tetapi karena tidak, Anda perlu melihat statistik untuk melihat informasi seperti pembacaan logis yang dilakukan oleh setiap utas CPU.
Namun, SQL Server hanya menetapkan tugas ini ke beberapa utas, tidak semuanya. Brent menjelaskan bahwa semua yang terjadi di luar ikon paralel hanya terjadi pada prosesor yang ditetapkan. Jadi, utas yang melakukan pembacaan awal sekarang menjadi satu-satunya yang juga melakukan pencarian kunci. Tuan robot hanya meminta beberapa antek untuk melakukan seluruh tugas alih-alih meminta semua antek untuk ikut campur.
Dia melanjutkan untuk menjelaskan bahwa SQL Server harus memperhitungkan apa yang dilakukan utas serta melacak apa yang dilakukan robot penguasa. Pada hari-hari awal, semua pekerjaan ini diwakili oleh satu statistik menunggu, tetapi ini tidak masuk akal karena tidak peduli apa, tuan masih harus menunggu sementara semua utas bekerja. Jadi, jenis tunggu baru diperkenalkan – ini adalah CXCONSUMER dan melacak apa yang dilakukan oleh thread scheduler/overlord, sementara CXPACKET melacak apa yang dilakukan oleh thread pekerja/antek.
Brent kembali ke kueri untuk membuatnya lebih kompleks dengan menambahkan pengurutan. Sekarang, menjadi lebih jelas bahwa paralelisme menyebabkan masalah daripada membuat operasi lebih efisien. Pekerjaan menjadi lebih tidak seimbang di beberapa utas pekerja, dan beberapa kehabisan memori dan tumpah ke disk. Ditambahkannya, semakin memberatkan inti yang bekerja yang tidak mendapatkan bantuan dari yang tidak bekerja. Statistik CXPACKET terus meningkat.
Apa yang dapat Anda lakukan dalam situasi ini? Keputusan paralelisme terjadi di tingkat server dan bukan di tingkat kueri, sehingga akan memerlukan beberapa perubahan konfigurasi.
Menilai konfigurasi kunci
Kami telah mempelajari bahwa jika biaya kueri lebih tinggi dari level tertentu, hal itu menyebabkan SQL Server diparalelkan. Kueri kecil dibatasi ke satu utas. Tapi apa yang mengontrol ambang batas? Ini adalah properti yang disebut Ambang Biaya untuk Paralelisme (CTFP). Secara default, jika rencana eksekusi menentukan biaya lebih tinggi dari 5 dolar kueri, kueri akan diparalelkan. Meskipun tidak ada panduan tentang cara menyetel ini, Brent merekomendasikan angka yang lebih besar dari 50. Ini akan menghilangkan paralelisme untuk kueri sepele.
Konfigurasi lainnya adalah derajat paralelisme maksimum (MAXDOP) yang menjelaskan jumlah utas yang akan ditetapkan SQL Server ke kueri. Nilai default di sini adalah nol, yang berarti SQL Server dapat menggunakan semua prosesor yang tersedia, hingga 64, untuk menjalankan kueri. Menyetel opsi MAXDOP ke 1 membatasi SQL Server untuk hanya menggunakan satu prosesor – akibatnya, memaksa rencana serial untuk mengeksekusi kueri. SQL Server akan merekomendasikan nilai MAXDOP berdasarkan jumlah inti server yang Anda miliki, tetapi umumnya, MAXDOP yang lebih rendah masuk akal karena tidak akan ada banyak waktu bahwa semua inti diperlukan.
Brent membuat penyesuaian pada dua konfigurasi ini dan menjalankan kuerinya lagi. Kali ini, kita dapat melihat bahwa lebih banyak inti yang terlibat dalam operasi paralel. Statistik tunggu CXPACKET lebih rendah yang berarti beban lebih seimbang di lebih banyak inti daripada sebelumnya.
Kiat untuk memerangi statistik tunggu CXPACKET dan CXCONSUMER
Brent merekomendasikan langkah-langkah berikut jika Anda melihat statistik menunggu CXPACKET dan CXCONSUMER yang berlebihan:
- Tetapkan CTFP dan MAXDOP per praktik terbaik industri, lalu biarkan setelan tersebut berjalan selama beberapa hari. Tindakan ini akan menghapus cache paket dan memaksa SQL Server untuk membangun kembali rencana eksekusi kueri (mengevaluasi kembali biaya).
- Buat peningkatan indeks yang akan mengurangi waktu saat kueri paralel untuk melakukan pemindaian dan pengurutan. Biarkan indeks baru dipanggang, lalu cari kueri yang masih banyak pekerjaan.
- Sesuaikan kueri tersebut dan biarkan matang selama beberapa hari.
- Terakhir, jika paralelisme masih menjadi masalah serius, mulailah mencari kueri khusus dengan masalah paralelisme.
Untuk wawasan lebih lanjut, Anda dapat melihat seluruh sesi pelatihan Brent tentang statistik tunggu CXPACKET dan CXCONSUMER sesuai permintaan di bawah ini.
