Dampak dari peristiwa yang diperluas query_post_execution_showplan di SQL Server 2012

Salah satu tantangan terberat di SQL Server adalah pemecahan masalah dengan sensitivitas parameter atau estimasi kardinalitas yang menyebabkan penurunan kinerja beban kerja. Umumnya Anda harus memiliki rencana eksekusi aktual dari pernyataan yang berjalan untuk dapat menentukan penyebab penurunan kinerja. Di SQL Server 2012, query_post_execution_showplan Extended Event menyediakan kemampuan untuk menangkap rencana eksekusi aktual untuk pernyataan. Namun, meskipun tampaknya berguna, peristiwa ini bukanlah sesuatu yang dapat digunakan tanpa dampak kinerja yang signifikan pada beban kerja yang berjalan di server.

Dalam artikel saya Mengukur “Observer Overhead” dari SQL Trace vs. Extended Events, saya menunjukkan perbandingan dampak kinerja SQL Trace terhadap konfigurasi identik menggunakan Extended Events di SQL Server 2012.  Pada saat saya pertama kali melakukan pengujian untuk artikel tersebut Saya juga melakukan banyak pengujian peristiwa query_post_execution_showplan di SQL Server 2012.  Peristiwa ini pertama kali diperkenalkan di SQL Server 2012 CTP1 ketika banyak peristiwa pelacakan dipindahkan ke Peristiwa yang Diperpanjang untuk memberikan keseimbangan dengan SQL Trace. Saat itu acara hanya memiliki subset kolom yang disertakan dalam RTM final SQL Server 2012.

Selama CTP1 saya mengirimkan item Connect yang meminta tindakan dibuat untuk memungkinkan kumpulan rencana eksekusi aktual dengan peristiwa di SQL Server 2012.  Tujuannya adalah untuk dapat menggunakan peristiwa module_end atau sql_statement_completed untuk mengidentifikasi kapan eksekusi prosedur atau pernyataan melebihi durasi normalnya. Misalnya, dalam skenario sensitivitas parameter, di mana rencana yang kurang ideal dihasilkan untuk nilai parameter normal, peristiwa tersebut dapat digunakan untuk mengumpulkan rencana eksekusi aktual untuk pernyataan itu melalui suatu tindakan. Sebagai tanggapan, tim SQL Server menambahkan kolom durasi dan cpu_time ke peristiwa query_post_execution_showplan untuk memungkinkan definisi predikat hanya mengumpulkan peristiwa ini untuk skenario tersebut.

Sayangnya ini tidak memiliki manfaat yang sama dengan implementasi sebagai tindakan terhadap kinerja. Di sisa postingan ini, saya akan menjelaskan alasannya.

Dampak Kinerja

Pada saat saya melakukan pengujian untuk artikel saya sebelumnya, saya juga menguji overhead yang terkait dengan acara query_post_execution_showplan, terutama karena saya sangat tertarik untuk menggunakannya dalam beberapa sistem produksi klien dan sebelum saya melakukannya, saya perlu memahami apa jenis dampak acara tersebut pada beban kerja mereka. Saya benar-benar kecewa dengan hasil yang saya dapatkan dari pengujian asli saya, dan setelah Aaron Bertrand memvalidasi hasil saya menggunakan rangkaian uji internal SQL Sentry, saya mengajukan item Connect lain yang melaporkan masalah kinerja yang kemudian ditutup sebagai "Dengan Desain" .

Untuk menguji dampak kinerja, beban kerja yang sama persis dan konfigurasi Pemutaran Ulang Terdistribusi dari artikel Mengukur "Observer Overhead" dari SQL Trace vs. Extended Events digunakan. Satu-satunya perbedaan untuk hasil pengujian yang ditampilkan dalam artikel ini adalah bahwa sistem host yang lebih baru dan lebih kuat digunakan untuk lingkungan VM. VM yang digunakan persis sama, tanpa perubahan pada konfigurasinya, dan mereka hanya disalin ke sistem baru, itulah sebabnya beban kerja dasar dapat melakukan pemutaran ulang lebih cepat dengan Permintaan Batch rata-rata yang lebih tinggi/dtk. Hasil dasar diambil menggunakan penginstalan SQL Server 2012 standar dengan hanya sesi acara system_health default yang berjalan di server.

Untuk perbandingan dampak kinerja query_post_execution_showplan acara, definisi sesi acara berikut digunakan.

CREATE EVENT SESSION [query_post_execution_showplan Overhead]
ON SERVER
ADD EVENT sqlserver.query_post_execution_showplan(
WHERE ([duration]=(5000000)));
GO

Sesi ini sebenarnya tidak mengumpulkan data peristiwa menggunakan target dan menggunakan predikat durasi karena durasi peristiwa sama dengan 5000000 mikrodetik, atau durasi lima detik. Untuk beban kerja replay, tidak ada eksekusi pernyataan yang memiliki durasi tepat lima detik, sehingga event query_post_execution_showplan tidak pernah benar-benar diaktifkan di server, dan penurunan performa apa pun adalah hasil dari pengumpulan data event dan kemudian evaluasi predikat. Hasil dari pengujian ditunjukkan pada Tabel 1 dan dipetakan pada Bagan 2.

Tabel 1 – overhead acara query_post_execution

Bagan 2 – overhead acara query_post_execution

Untuk putaran pengujian ini, kinerja beban kerja menurun sekitar 30% hanya dengan mengaktifkan acara ini di sesi acara, meskipun itu tidak akan diaktifkan untuk acara apa pun yang sedang diputar ulang di server. Degradasi keseluruhan akan tergantung pada beban kerja sebenarnya untuk server, dan penting untuk dicatat bahwa rangkaian tes ini mencerminkan lebih banyak skenario terburuk karena Pemutaran Ulang Terdistribusi dijalankan dalam mode stres dan penggunaan CPU pada SQL Server dipatok rata-rata 94% selama pengujian.

Memahami Dampak Kinerja

Alasan peristiwa ini membebankan overhead yang signifikan pada kinerja dapat dijelaskan dari siklus hidup peristiwa di Peristiwa yang Diperpanjang. Ketika titik kritis dalam kode SQL Server yang terkait dengan suatu peristiwa ditemui selama eksekusi, kode tersebut melakukan pemeriksaan Boolean yang sangat cepat untuk menentukan apakah peristiwa tersebut diaktifkan dalam setiap sesi peristiwa aktif di server. Jika acara diaktifkan untuk sesi acara aktif, semua kolom data yang terkait dengan acara dikumpulkan, termasuk kolom yang dapat disesuaikan yang telah diaktifkan. Pada titik ini, acara mengevaluasi predikat apa pun untuk sesi acara aktif yang mengumpulkan acara untuk menentukan apakah acara benar-benar akan diaktifkan sepenuhnya.

Untuk acara query_post_exection_showplan, semua dampak kinerja berasal dari overhead yang terkait dengan pengumpulan data. Bahkan dalam kasus di mana ada predikat untuk durasi sama dengan lima detik, hanya dengan mengaktifkan acara di sesi acara, ia harus mengumpulkan XML Showplan untuk setiap pernyataan yang dijalankan di server hanya untuk dapat mengevaluasi predikat dan kemudian menentukan bahwa acara tersebut tidak akan menyala. Untuk alasan ini, acara query_post_execution_showplan harus dihindari untuk beban kerja produksi. Untuk beban kerja pemutaran ulang pengujian, peristiwa tersebut harus dievaluasi kira-kira 440.000 kali, meskipun tidak benar-benar diaktifkan untuk beban kerja dan sesi peristiwa yang diuji karena tidak ada peristiwa tayangan ulang yang berdurasi tepat lima detik. Informasi jumlah peristiwa dikumpulkan dengan menambahkan target event_counter ke sesi peristiwa dan menghapus predikat durasi, lalu menguji ulang beban kerja pemutaran ulang dengan definisi sesi berikut.

CREATE EVENT SESSION [query_post_execution_showplan Overhead] 
ON SERVER
ADD EVENT sqlserver.query_post_execution_showplan
ADD TARGET package0.event_counter;
GO

Perbandingan dengan Peristiwa Peluncuran Cepat

Untuk memberikan kerangka acuan untuk dampak kinerja ini, kita dapat melihat biaya tambahan untuk mengaktifkan serangkaian peristiwa yang sering dijalankan di server dan melakukan beban kerja pemutaran ulang yang sama. Dua dari event yang paling sering dieksekusi di SQL Server adalah event lock_acquired dan lock_released. Untuk membandingkan overhead dari dua peristiwa ini, sesi peristiwa berikut dapat digunakan, yang mengumpulkan peristiwa tanpa predikat sehingga setiap eksekusi dikumpulkan dan menghitung seberapa sering mereka diaktifkan menggunakan target event_counter.

CREATE EVENT SESSION [locking Overhead] 
ON SERVER
ADD EVENT sqlserver.lock_acquired,
ADD EVENT sqlserver.lock_released
ADD TARGET package0.event_counter;
GO

Untuk beban kerja replay kami, dua peristiwa ini menyala sekitar 111.180.000 kali. Overhead yang terkait dengan pengumpulan acara ini dapat dilihat pada Tabel 3 dan Bagan 4.

Tabel 3 – Mengunci perbandingan overhead

Bagan 4 – Mengunci perbandingan overhead peristiwa

Seperti yang Anda lihat dari data, efek kinerja peristiwa ini secara signifikan lebih rendah daripada query_post_execution_showplan, meskipun definisi sesi peristiwa penguncian dikonfigurasi untuk memungkinkan semua peristiwa diaktifkan di server, total overhead di bawah 1% secara keseluruhan . Ingatlah bahwa sesi acara penguncian mengevaluasi setara dengan 500 kali lebih banyak peristiwa, dan dalam hal ini semua peristiwa benar-benar harus diaktifkan untuk sesi acara, di mana acara query_post_execution_showplan tidak benar-benar harus diaktifkan setelah dievaluasi.

Ringkasan

Sementara acara query_post_execution_showplan menyediakan kemampuan untuk mengumpulkan rencana kueri aktual untuk pernyataan yang dijalankan, dampak kinerja pengumpulan data hanya untuk mengevaluasi acara menjadikannya sesuatu yang tidak layak untuk penggunaan produksi. Minimal, overhead harus dipertimbangkan sebelum Anda menggunakan acara ini untuk beban kerja produksi. Bahkan deskripsi acara yang disediakan oleh Microsoft mengakui bahwa acara tersebut dapat memiliki dampak kinerja yang signifikan (penyorotan saya):

Deskripsi acara dapat ditemukan di kolom deskripsi tampilan katalog sys.dm_xe_objects, atau di UI Sesi Baru seperti yang ditunjukkan pada Gambar 5 (penyorotan saya):

Gambar 5 – Deskripsi acara dari UI Sesi Baru

Saya akan merekomendasikan membandingkan kinerja peristiwa apa pun dengan peringatan ini dalam deskripsi sebelum benar-benar menggunakannya di lingkungan produksi.