CXPACKET(Class Exchange Packet), SQL Server’da bir sorgunun birden fazla işlemci çekirdeği (CPU) kullanılarak çalıştırılması durumunda ortaya çıkan bir bekleme türüdür. Teknik olarak; paralel bir işlemin bir veya birden fazla worker thread’inin işini bitirip, aynı gruptaki diğer thread’lerin işini tamamlamasını beklemesi durumudur.
Bir sorgu Parallel Plan ile çalıştığında, ana thread (Control Thread) işi küçük parçalara böler ve bunları alt threadlere (Sub-processes) dağıtır.
- Eğer bir thread kendisine verilen 100 satırı 1 ms’de işlerken, diğer thread 1 milyon satırı işlemek zorunda kalırsa (Data Skew), işini erken bitiren thread “Ben hazırım, diğerlerini bekliyorum” der.
- İşte bu bekleme süresi, SQL Server istatistiklerine CXPACKET olarak yansır.
SQL Server’ın paralellik kullanması istenen bir durumdur. CXPACKET değerinin sistemdeki toplam beklemelerin %20-%30’u civarında olması genellikle normal kabul edilir.
Kritik Fark: Eğer CXPACKET beklemesine CXCONSUMER eşlik ediyorsa, bu genellikle zararsızdır. CXCONSUMER, bir thread’in sadece pasif bir şekilde veri beklediğini gösterir ve SQL Server 2016 SP2 sonrası “ignore” edilebilir bir değer olarak kabul edilir.
Yüksek CXPACKET değerleri gördüğünüzde doğrudan “Paralelliği kapatmalıyım” demek yerine şu adımları izlemelisiniz:
- Verinin threadler arasında dengesiz dağılmasının en büyük sebebi güncel olmayan istatistiklerdir. SQL Server verinin boyutunu yanlış tahmin ederse, threadlere dengesiz iş yükü verir.
- SQL Server’ın “kaç paralık” işten sonra paralel plana geçeceğini belirleyen ayardır. Varsayılan değeri 5‘tir, bu çok düşüktür. En küçük sorgular bile paralel çalışmaya çalışarak sisteme yük bindirir. Bu değeri 50‘ye çekmek, küçük sorguların tek çekirdekte (Serial Plan) hızlıca bitmesini sağlar ve CXPACKET’i ciddi oranda düşürür.
- Bir sorgunun maksimum kaç çekirdek kullanabileceğini belirler. Eğer 64 çekirdekli bir makinede bu değer 0 (varsayılan) ise, tek bir sorgu 64 çekirdeği de meşgul edebilir. Genellikle bir NUMA node üzerindeki çekirdek sayısı (8 idealdir) olarak set edilmelidir.
Sisteminizdeki CXPACKET durumunu analiz etmek için şu sorguları kullanabilirsiniz:
Bekleme Tiplerinin Oranını Görmek:
SELECT wait_type,
wait_time_ms / 1000.0 AS Wait_Saniye,
100.0 * wait_time_ms / SUM(wait_time_ms) OVER() AS Yuzde
FROM sys.dm_os_wait_stats
WHERE wait_type NOT IN ('SLEEP_TASK', 'BROKER_EVENT_HANDLER', 'DIRTY_PAGE_POLL')
ORDER BY wait_time_ms DESC;
CXPACKET Alan Sorguları Anlık Yakalamak:
SELECT session_id, wait_type, wait_duration_ms, blocking_session_id, resource_description
FROM sys.dm_os_waiting_tasks
WHERE wait_type = 'CXPACKET'
ORDER BY wait_duration_ms DESC;
- Düşük CPU Kullanımı + Yüksek CXPACKET: Genellikle yanlış yapılandırma veya Cost Threshold düşüklüğüdür.
- Yüksek CPU Kullanımı + Yüksek CXPACKET: Bir sorgu veriyi işlemek yerine thread yönetimi için CPU harcıyor demektir. Sorgu optimizasyonu (Index ekleme) gerekir.
CXPACKET bir hastalık değil, bir belirtidir. Çözüm yolu her zaman paralelliği kısıtlamak değil, SQL Server’ın neden paralel çalışırken zorlandığını (Eksik index, eski istatistik, yanlış sunucu konfigürasyonu) bulmaktır.
Başka makalede görüşmek dileğiyle..
İsraf etmeyin. İsra-26
