HADR penggunaan pekerja yang tinggi

Mengapa jumlah utas kelompok pekerja dalam kumpulan HADR meningkat jauh melampaui penggunaan minimum " biasanya, ada 3–10 utas yang dibagikan " per replika?

Dalam satu kasus kami telah mengamati penggunaan 300+ utas dengan 3 grup ketersediaan dan total 10 basis data. SQL Server 2014 SP1.

Prospek kami adalah cadangan untuk replika sekunder, aktivitas tinggi pada replika primer, laporan tentang replika sekunder.

AG berada di pusat data di VMware. Total 16 penjadwal, utas pekerja biasa berada di bawah kisaran 200. max_dop di server adalah 2.

3 AG, 10 DB, 4 replika masing-masing - primer, 2 hanya baca, 1 tidak dapat dibaca.
1 sekunder adalah selaras, 2 asinkron
16 vcores pada 32 core fisik pada cluster multi-host besar.
Tidak ada overprovision.
Inti VM kecil 4-8 lainnya dikolokasi, tetapi tidak menekan CPU

Kami mengamati lonjakan benang pekerja yang mengakibatkan penolakan layanan. Atribusi utas pekerja ke AG adalah asumsi kami, karena hanya utas pekerja yang bisa melewati batas.

Tautan di bawah dari Blog Field Engineer SQL Server Premier yang dibaca dalam konteks tidak memberikan jawaban lengkap kepada saya:

— Alexander Tarasul
sumber

Bisakah Anda memposting contoh tangkapan layar dari apa yang Anda lihat? Sepertinya ada yang salah di sini, seperti Anda sedang menanyakan utas pekerja secara umum yang bertentangan dengan yang khusus AG. (Dan utas pekerja lainnya juga dapat melewati batas, tidak hanya yang AG.)

— Brent Ozar

Saya berburu masalah serupa. Cukup yakin saya telah memakukannya ke masalah MaxDop. Saya menggunakan skrip Ola Hallengreens untuk IndexMaintenance, dan pengaturan MaxDOP ditetapkan pada NULL. Intinya adalah, bisakah Anda memiliki pertanyaan yang masuk, yang mengesampingkan MaxDOP 2 Anda?

— Kasper Brandenburg

Apakah Anda mendapatkan solusi untuk ini?

— trusha

-1

Karena DC Anda menggunakan VM, saya curiga Anda mengalami kinerja disk yang buruk. Performa disk yang buruk dapat menyebabkan waktu penulisan log yang lebih lambat pada sekunder yang dapat menghasilkan pengakuan yang lebih lambat kembali ke replika primer dari replika sekunder (utas pekerja yang melelahkan).

Disk latensi pada Replika Sekunder dapat menyebabkan peningkatan dalam proses Komit Sinkronisasi HADR, yang mengakibatkan Pratama memegang utas terbuka sambil menunggu Sekunder mengakui transaksi.

Silakan periksa log kesalahan untuk Penjadwal yang Terkunci dan kumpulkan beberapa metrik IO dari PerfMon untuk melihat latensi disk dan panjang antrian disk.

— Rodrigo Nascentes
sumber