CLR_AUTO_EVENT, bir iş parçacığının (thread) o an aktif olarak bir işlem yapmadığını ve CLR içindeki bir senkronizasyon olayının (event) tetiklenmesini beklediğini ifade eder.
SQL Server, CLR ile entegre çalışırken kendi zamanlayıcısını (SQLOS) kullanır. Bu bekleme türü, genellikle CLR’ın kendi iç yönetimi (çöp toplama, thread yönetimi vb.) sırasında oluşur.
Bu bekleme tipini gördüğünüzde panik yapmanıza gerek yoktur; çünkü çoğu zaman “boşta bekleme” (idle wait) kategorisine girer. En yaygın görüldüğü senaryolar şunlardır:
- Boşta Bekleme (Idle State): CLR yüklüdür ancak aktif olarak bir CLR prosedürü veya fonksiyonu çalıştırılmıyordur. Bu durumda CLR motoru bir görev gelmesini bekler.
- Yüksek CLR Kullanımı: Eğer veritabanınızda yoğun şekilde Stored Procedure, Trigger veya User Defined Function (UDF) olarak yazılmış .NET kodları varsa, bu kodların birbiriyle senkronizasyonu sırasında bu bekleme artabilir.
- Garbage Collection (Çöp Toplama): .NET tarafında bellek yönetimi yapılırken (GC süreci), threadler geçici olarak askıya alınabilir ve bu durum CLR_AUTO_EVENT olarak kaydedilir.
- Safe/External Access Modları: CLR nesnelerinizin güvenlik seviyeleri ve dış kaynaklara erişim çabaları sırasında oluşan iç beklemeler.
CLR_AUTO_EVENT, SQL Server’ın LAZYWRITER_SLEEP veya CHECKPOINT_QUEUE gibi zararsız “bekleme” türlerine benzer. Performans raporlarınızda (örneğin Query Store veya sys.dm_os_wait_stats) bu değeri çok yüksek görüyorsanız şuna dikkat etmelisiniz:
- Toplam Süre (Wait Time) vs. Bekleme Sayısı (Waiting Tasks): Eğer bekleme süresi çok yüksek ama sistemde bir performans yavaşlığı hissedilmiyorsa, bu sadece CLR’ın arka planda “uyuduğu” anlamına gelir.
- Diğer CLR Beklemeleri: Eğer CLR_AUTO_EVENT ile birlikte CLR_CRITICAL_SECTION veya CLR_MONITOR gibi beklemeler de yüksekse, o zaman .NET kodunuzda bir kilitleme (locking) veya darboğaz sorunu olabilir.
Eğer bu bekleme tipinin bir soruna işaret ettiğinden şüpheleniyorsanız şu adımları izleyebilirsiniz:
- Kod Optimizasyonu: CLR içinde çalışan .NET kodlarınızın karmaşıklığını ve bellek kullanımını inceleyin.
- Bellek Durumu: SQL Server’ın Max Server Memory ayarının CLR için yeterli alan bıraktığından emin olun (CLR, SQL Server’ın buffer pool dışındaki bellek alanını da kullanabilir).
- İstatistikleri Sıfırlayıp Gözlemleyin: Aşağıdaki komutla beklemeleri sıfırlayıp, sadece yoğun kullanım anında ne kadar arttığını gözlemleyin:
SQLDBCC SQLPERF ('sys.dm_os_wait_stats', CLEAR);CLR_AUTO_EVENT genellikle sistemin sağlıklı işleyişinin bir parçasıdır. Ancak sisteminizde yoğun CLR kullanımı varsa ve bu bekleme tipi CLR_CRITICAL_SECTION ile eşleşiyorsa kod seviyesinde inceleme yapmanız gerekir.
Başka makalede görüşmek dileğiyle..
İyilikler için karşılık beklemeyin. İnsan-9
