Apa kemungkinan penyebab sp_reset_connection membutuhkan waktu lama untuk dieksekusi?

Mengapa sp_reset_connectionprosedur yang disimpan sistem membutuhkan waktu lebih dari beberapa milidetik untuk dijalankan, seperti yang dilihat melalui SQL Server Profiler?

Saya mengambil jejak sederhana dari sistem produksi menggunakan SQL Server Profiler dan kemudian menggunakan SqlNexus untuk menganalisisnya. SqlNexus menunjukkan bahwa sp_reset_connection memiliki durasi kumulatif tertinggi - 33% dari keseluruhan jejak. Durasi yang diamati berkisar antara 0-7 detik (12 hingga 6.833.270 mikrodetik) tetapi rata-rata pada 0,956s.

Saya mengerti bahwa sp_reset_connection dipanggil ketika koneksi yang dikumpulkan digunakan kembali. Saya telah melihat saran bahwa ini bisa terjadi karena jejak yang asing , tetapi sepertinya tidak demikian.

Saya telah membaca apa yang dilakukan server ketika sproc dipanggil tetapi saya tidak percaya ada yang bermasalah dalam kasus ini - kode tidak meninggalkan transaksi terbuka atau tabel sementara besar yang perlu dibersihkan.

Saya juga melihat /server/199974/sp-reset-connection-taking-a-long-time-to-run tetapi itu tidak membantu.

EDIT (2013-12-23): Dalam semua kasus, baca dan tulis adalah 0 dan CPU hampir selalu 0 (hanya dua contoh CPU non-nol, keduanya pada 16ms).

sql-server sql-server-2008

— Pengembang Holistik
sumber

Nilai apa yang Anda lihat untuk dibaca dan ditulis dalam acara itu?

— Martin Smith

Bisakah Anda memberikan info lebih lanjut tentang jenis pertanyaan yang Anda jalankan. Detail khusus yang menarik seperti, transaksi panjang atau kompleks, pemrosesan XML, tabel temp?

— Edward Dortland

@Martin membaca dan menulis adalah 0. Memperbarui pertanyaan. (Tidak memiliki akses ke data selama akhir pekan.)

— Holistic Developer

@EdwardDortland sebagian besar kueri adalah pemilihan dan pembaruan yang cukup sederhana tanpa transaksi eksplisit atau penggunaan tabel temp. Bahkan, biasanya permintaan aktual dieksekusi pada koneksi ini cukup cepat - hanya beberapa ms.

— Pengembang Holistik

@ HolisticDeveloper - Saya bereksperimen dengan meninggalkan transaksi terbuka dan bisa melihat bukan nol membaca dan menulis di sana jadi setuju itu tidak terlihat seperti itu kalau begitu. Apakah situasi ini lebih atau kurang permanen? jika demikian saya akan menjalankan jejak peristiwa yang diperpanjang menangkap RPC:Starting, RPC:Completeddan menunggu jenis untuk periode singkat kemudian melihat melalui data untuk melihat jenis menunggu apa yang dihadapi spid selama waktu itu.

— Martin Smith

Jawaban:

Akhirnya sempat menulis jawaban yang lebih detail.

Biasanya ada tiga alasan utama prosedur sederhana seperti sp_reset_connectionakan membutuhkan waktu lama untuk dijalankan.

Anda sedang menunggu sumber daya CPU
Anda diblokir pada kunci di suatu tempat (mungkin karena DML atau transaksi yang bersaing)
Jaringan Anda lambat dan butuh waktu lama untuk mengembalikan hasilnya ke klien

Iklan 1) Jika Anda menunggu sumber daya CPU, ini akan muncul sebagai menunggu sinyal. Silakan lihat komentar saya pada pertanyaan Anda tentang cara mendiagnosis jika ini masalahnya

Iklan 2) Jika Anda menunggu kunci, ini paling baik didiagnosis dengan membandingkan dua foto sys.dm_os_wait_stats. Lihat artikel ini tentang cara melakukan ini:

http://www.sqlsoldier.com/wp/sqlserver/sqludbaweekbeanefficientdba

Jika Anda melihat lama menunggu LCK_ [Sesuatu], kueri sys.dm_tran_locksuntuk melacak objek mana yang sedang dikunci. Dalam kasus Anda, saya berharap melihat beberapa bentuk kunci SCH- [Sesuatu]> yang menghalangi Anda.

Iklan 3) Cara termudah untuk mendiagnosis masalah jaringan untuk pertama-tama mencari OLEDB dan ASYNC_NETWORK_IO menunggu di langkah 2 (jika Anda menunggu lama untuk jaringan, salah satunya muncul). Jika menunggu itu tinggi, gunakan xperf -on latencyatau program pemantauan jaringan seperti netmon atau wireshark untuk memeriksa latensi Anda. Jika jaringan terlihat lambat, ini juga bisa disebabkan oleh server aplikasi panggilan tidak merespon cukup cepat untuk koneksi yang didaur ulang.

— Thomas Kejser
sumber

Saya belum melihat masalah ini berulang sehingga saya tidak dapat menggunakan jawaban yang disediakan untuk mendiagnosis lebih lanjut pada saat ini. Namun, saya menerima jawaban berdasarkan reputasi Anda sebagai ahli kinerja SQL Server.

— Pengembang Holistik

Saya baru saja menemukan artikel KB untuk bug yang mungkin terkait dengan masalah ini. Di FIX: Masalah kinerja terjadi ketika aktivitas kunci basis data meningkat di SQL Server (KB 2926217), salah satu gejala yang dijelaskan adalah yang sp_reset_connectionmungkin membutuhkan waktu lama untuk menyelesaikan. Perbaikan terbaru termasuk dalam pembaruan berikut:

Pembaruan kumulatif 17 untuk SQL Server 2008 SP3
Pembaruan kumulatif 13 untuk SQL Server 2008 R2 SP2
Pembaruan kumulatif 9 untuk SQL Server 2012 SP1
Pembaruan Kumulatif 1 untuk SQL Server 2014

Server tempat saya mengamati perilaku ini menjalankan SQL Server 2008 SP3 dengan Pembaruan Kumulatif 5, jadi mungkin saja ia mengalami bug ini. Saya belum mencoba pembaruan kumulatif (masalah tidak berulang setiap saat) jadi saya tidak dapat memverifikasi apakah akan memperbaikinya atau tidak. Namun, saya ingin memberikan info kalau-kalau ada yang memiliki gejala yang sama.

— Pengembang Holistik
sumber