SQL Server’da LOGMGR_QUEUE bekleme tipi, adından da anlaşılacağı üzere Transaction Log yöneticisinin iş kuyruğunda bir birikme olduğunu gösterir. Bu bekleme tipi genellikle sistemin veriyi diske yazma hızından ziyade, içsel yönetim süreçlerindeki bir tıkanıklığa işaret eder.
SQL Server’da bir veri değişikliği yapıldığında (INSERT, UPDATE, DELETE), bu işlem önce Transaction Log’a kaydedilir. Log Manager, bu kayıtların sırayla ve güvenli bir şekilde işlenmesini koordine eder.
LOGMGR_QUEUE beklemesi, bir “worker thread”in (çalışan iş parçacığı) Log Manager’a bir görev gönderip, bu görevin kuyruğa alınmasını beklediği anlarda oluşur. Genellikle sistem boşta olduğunda veya log yazma işlemleri çok hızlı gerçekleştiğinde bu bekleme tipi önemsizdir. Ancak süreler uzadığında bir darboğaz belirtisidir.
En Yaygın Nedenleri ve Çözümleri
1. Çok Sık “Commit” Yapılması
Eğer bir uygulama, her bir satır için ayrı bir INSERT ve COMMIT işlemi yapıyorsa (örneğin bir döngü içinde binlerce kez), Log Manager her seferinde logu diske “flush” etmek (boşaltmak) zorunda kalır. Bu da kuyrukta yığılmaya neden olur.
İşlemleri Batch (Toplu) haline getirin. 10.000 satırı tek bir transaction içinde göndermek, 10.000 ayrı transaction’dan çok daha verimlidir.
2. Transaction Log Dosyası Yavaşlığı
Log dosyasının (.ldf) bulunduğu disk biriminin gecikme süresi (Latency) yüksekse, kuyruk hızla dolar.
Log dosyalarını sistemdeki en hızlı disklere (mümkünse NVMe veya SSD) taşıyın. Log dosyası yazma hızı, SQL Server performansının en kritik noktasıdır.
3. VLF (Virtual Log File) Sayısının Fazlalığı
Eğer log dosyanız çok küçük adımlarla (örneğin 1MB, 10MB) binlerce kez büyüdüyse, içinde çok fazla VLF oluşur. Bu durum Log Manager’ın dosyayı yönetmesini zorlaştırır.
Log dosyasını küçültün (shrink) ve mantıklı bir başlangıç boyutuyla tek seferde büyütün.
4. Always On veya Mirroring Gecikmeleri
Eğer veritabanınız bir “Availability Group” (AG) üyesiyse, log kayıtlarının ikincil sunucuya (Secondary) gönderilmesi gerekir. İkincil sunucudaki bir yavaşlık veya ağ gecikmesi, ana sunucudaki Log Manager kuyruğunu şişirebilir. Senkronizasyon modlarını ve ağ bant genişliğini kontrol edin.
Aşağıdaki sorgu ile bu beklemenin sisteminizdeki ağırlığını kontrol edebilirsiniz:
SELECT wait_type,
wait_time_ms / 1000.0 AS Total_Wait_Sec,
waiting_tasks_count,
CASE WHEN waiting_tasks_count = 0 THEN 0
ELSE wait_time_ms / waiting_tasks_count END AS Avg_Wait_Ms
FROM sys.dm_os_wait_stats
WHERE wait_type = 'LOGMGR_QUEUE'
ORDER BY wait_time_ms DESC;Eğer bu değer yüksekse, ilk bakmanız gereken yer disk gecikmeleri (Disk Latency) ve uygulamanın commit sıklığıdır.
Başka makalede görüşmek dileğiyle..
Boş konuşmalardan kaçının Müminin-3
