Kasus HADR_SYNC_COMMIT yang aneh menunggu

Kami memperhatikan pola HADR_SYNC_COMMITmenunggu yang menarik di lingkungan kami. Kami memiliki tiga replika; satu primer, satu sinkronisasi sekunder dan satu asinkron sekunder dalam pusat data dan kami baru saja menambahkan tiga replika ASYNC lainnya dalam pusat data lain (~ terpisah 2.400 mil).

Sejak itu, kami mulai melihat peningkatan yang sangat besar dalam HADR_SYNC_COMMITmenunggu. Ketika kita melihat sesi aktif, kita melihat banyak COMMIT TRANSACTIONpertanyaan menunggu pada replika SYNC

Dari tangkapan layar, kita dapat dengan jelas melihat ada lompatan dalam HADR_SYNC_COMMITmenunggu pada tanggal 29 Juni, dan kami akhirnya menjatuhkan 'dua' dari tiga replika async di pusat data jarak jauh sekitar tengah hari pada tanggal 1 Juli. Itu membuat waktu tunggu sangat lama.

Apa yang telah kami periksa sejauh ini - Log antrian kirim, Ulangi antrian, waktu hardened terakhir dan waktu komit terakhir pada replika jarak jauh. Kami memiliki semburan transaksi kecil terus menerus selama jam kerja, dan oleh karena itu antrian pengiriman cukup kecil pada stempel waktu tertentu (di mana saja antara 60KB dan 1MB).
Replika jarak jauh hampir sinkron, ada sedikit perbedaan antara waktu komit terakhir dan waktu yang diperkeras terakhir untuk setiap lsn individu pada replika.

Pipa jaringan adalah 10G dan kami memodifikasi ukuran buffer transmisi dari 256 MB menjadi 2 gigs, ini dibuat dengan asumsi bahwa jaringan menjatuhkan paket dan mentransmisikannya kembali; apa pun itu tampaknya tidak banyak membantu.

Jadi, saya bertanya-tanya apa hubungannya replika ASYNC dengan HADR_SYNC_COMMITmenunggu? Bukankah replika SYNC bergantung pada jenis menunggu ini saja, apa yang saya lewatkan di sini?

Pertama, deskripsi acara tunggu yang menjadi pertanyaan Anda adalah:

Menunggu pemrosesan komit transaksi untuk database sekunder yang disinkronkan untuk mengeraskan log. Penantian ini juga tercermin oleh penghitung kinerja Penundaan Transaksi. Jenis tunggu ini diharapkan untuk grup ketersediaan yang disinkronkan dan menunjukkan waktu untuk mengirim, menulis, dan mengakui log ke database sekunder.

https://msdn.microsoft.com/en-us/library/ms179984.aspx

Menggali mekanisme menunggu ini Anda memiliki blok log sedang dikirim dan dikeraskan tetapi pemulihan tidak selesai pada server jauh. Karena hal ini dan mengingat bahwa Anda menambahkan replika tambahan, masuk akal bahwa HADR_SYNC_COMMIT Anda dapat meningkat karena peningkatan persyaratan bandwidth. Dalam hal ini Aaron Bertrand benar dalam komentarnya tentang pertanyaan itu.

Sumber: http://blogs.msdn.com/b/psssql/archive/2013/04/26/alwayson-hadron-learning-series-hadr-sync-commit-vs-writelog-wait.aspx

Menggali bagian kedua dari pertanyaan Anda tentang bagaimana penantian ini bisa terkait dengan pelambatan aplikasi. Ini saya percaya adalah masalah kausalitas. Anda melihat menunggu Anda meningkat dan keluhan pengguna baru-baru ini dan menarik kesimpulan berpotensi salah bahwa keduanya memiliki hubungan ketika ini mungkin tidak terjadi sama sekali. Fakta bahwa Anda menambahkan file tempdb dan aplikasi Anda menjadi lebih responsif kepada saya menunjukkan bahwa Anda mungkin telah memiliki beberapa masalah pertikaian mendasar yang bisa diperburuk oleh overhead tambahan dari overhead tingkat isolasi snapshot implisit ketika database berada dalam grup ketersediaan. Ini mungkin memiliki sedikit atau tidak ada hubungannya dengan menunggu HADR_SYNC_COMMIT Anda.

Jika Anda ingin menguji ini, Anda dapat menggunakan jejak peristiwa yang diperluas yang terlihat pada hadr_db_commit_mgr_update_harden XEvent pada replika utama Anda dan mendapatkan garis dasar. Setelah Anda memiliki baseline, Anda kemudian dapat menambahkan replika Anda kembali satu per satu dan melihat bagaimana jejaknya berubah. Saya sangat menyarankan Anda untuk menggunakan file yang berada pada volume yang tidak mengandung basis data apa pun dan menetapkan rollover dan ukuran maksimum. Harap sesuaikan filter durasi sesuai kebutuhan untuk mengumpulkan acara yang sesuai dengan waktu tunggu Anda sehingga Anda dapat memecahkan masalah lebih lanjut dan menghubungkannya dengan tim lain yang perlu dilibatkan.

CREATE EVENT SESSION [HADR_SYNC_COMMIT-Monitor] ON SERVER  -- Run this on the primary replica 
ADD EVENT sqlserver.hadr_db_commit_mgr_update_harden(
    WHERE ([delay]>(10))) -- I strongly encourage you to use the delay filter to avoid getting too many events back, this is measured in milliseconds
ADD TARGET package0.event_file(SET filename=N'<YourFilePathHere>')
WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=30 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=OFF,STARTUP_STATE=OFF)
GO