MSSQL Server’da CMEMTREAD Bekleme Tipi

SQL Server’da CMEMTHREAD bekleme tipi, sistemin “bellek tahsisatı” (memory allocation) sırasında bir thread çekişmesi yaşadığını gösterir.

Basitçe ifade etmek gerekirse: Birden fazla işlemci çekirdeği (thread), aynı anda aynı bellek nesnesinden (memory object) yer istemeye çalıştığında, bir “kapı önü kalabalığı” oluşur. SQL Server, bellek nesnesinin bütünlüğünü korumak için thread’leri sıraya dizer ve bu sırada bekleyenler CMEMTHREAD sinyali verir.

Bu bekleme tipi genellikle SQL Server’ın Plan Cache veya Workspace Memory yapılarıyla etkileşime girdiği anlarda ortaya çıkar. Temel nedenleri şunlardır:

• Ad-Hoc Sorgu Fırtınası: Uygulamanız her seferinde farklı parametrelerle (Literal SQL) binlerce küçük sorgu gönderiyorsa, SQL Server her biri için yeni bir plan oluşturup belleğe yazmaya çalışır. Bu, Plan Cache üzerinde yoğun bir bellek tahsisatı trafiği yaratır.
• Paralellik (Parallelism) Sorunları: Çok yüksek sayıda çekirdeğe (CPU) sahip sunucularda, birçok thread aynı anda bellek istediğinde bu bekleme tipi daha belirgin hale gelir.
• Eksik İstatistikler ve Derleme Yükü: Sorguların sürekli yeniden derlenmesi (recompile), bellek yöneticisini sürekli meşgul eder.
• Yetersiz NUMA Yapılandırması: SQL Server, bellek nesnelerini NUMA düğümlerine göre bölemezse, tüm çekirdekler tek bir noktaya yüklenir.

Eğer bu bekleme tipi sisteminizde en üst sıralardaysa, şu stratejileri uygulamanız gerekir:

A. Ad-Hoc Sorgu Yükünü Azaltın

Sistemin en büyük düşmanı parametreleştirilmemiş sorgulardır.

• Uygulama tarafında sp_executesql veya parametreli sorgular kullanın.
• Veritabanı veya sunucu seviyesinde optimize for ad hoc workloads seçeneğini ON konumuna getirin. Bu, planların sadece ikinci kez çağrıldığında tam olarak önbelleğe alınmasını sağlayarak bellek baskısını azaltır.

B. Sorgu Derleme Sayısını Takip Edin

Sürekli plan değişimi olup olmadığını kontrol edin.

• SQLServer:SQL Statistics altındaki SQL Compilations/sec ve SQL Re-Compilations/sec değerlerini izleyin. Eğer bu değerler saniyede yüzlerce ise sorun derleme yüküdür.

C. MAXDOP ve Cost Threshold for Parallelism

Sorguların çok fazla çekirdeğe parçalanması bellek ihtiyacını artırır.

• MAXDOP ayarının sunucunun NUMA yapısına uygun olduğundan emin olun. Cost Threshold for Parallelism değerini (genellikle default olan 5 çok düşüktür) 50 gibi daha mantıklı seviyelere çekin.

D. Güncel Service Pack ve Cumulative Update (CU)

Bu bekleme tipi bazen SQL Server’ın iç bellek yöneticisindeki bir hatadan (bug) kaynaklanabilir. Microsoft, belirli sürümlerde bellek nesnelerini daha fazla parçaya (partitioned memory objects) bölerek bu çekişmeyi azaltan yamalar yayınlamıştır.

Özetle

Belirti	Olası Neden	Aksiyon
Yüksek Ad-Hoc sorgu sayısı	Plan Cache şişmesi	optimize for ad hoc workloads = ON
Yüksek Derleme (Compilation) oranı	Sürekli değişen sorgular	Sorgu parametrizasyonu
Çok sayıda CPU çekirdeği (32+)	NUMA çekişmesi	MAXDOP ayarını ve CU güncellemelerini kontrol edin

Başka makalede görüşmek dileğiyle..

 “Allah’tan kulları içinde ancak ilim sahibi olanlar korkar.” Fâtır sûresi – 28