CXCONSUMER, SQL Server 2016 Service Pack 2 (SP2) ve SQL Server 2017 RTM CU3 sürümleriyle hayatımıza giren bir bekleme tipidir. Aslında bu bir “bekleme” değil, bir “durum” bildirimidir. Önceden tüm paralel işlem beklemeleri tek bir paket altında (CXPACKET) toplanıyordu. Microsoft, “zararlı” olan beklemeyle “doğal” olan beklemeyi ayırmak için CXCONSUMER tipini oluşturdu.
Paralel bir sorgu çalışırken, bir grup Worker Thread veriyi üretir (Producer), diğer bir grup veya ana thread ise bu veriyi paketleyip bir sonraki aşamaya iletir ya da sonuçlandırır. (Consumer).
- Producer (Üretici): Veriyi okuyan, filtreleyen ve işleyen kısımdır. Buradaki beklemeler CXPACKET olarak kaydedilir.
- Consumer (Tüketici): Üreticiden veri bekleyen kısımdır. Eğer üretici henüz veriyi hazırlamamışsa, tüketici boşta bekler. İşte bu “boşta bekleme” süresi CXCONSUMER‘dır.
CXPACKET ile CXCONSUMER Arasındaki Kritik Fark
| Özellik | CXPACKET (Producer) | CXCONSUMER (Consumer) |
| Anlamı | “İş yükü dengesiz, birileri çok çalışırken ben bekliyorum.” | “Benim görevim beklemek, verinin gelmesini gözlüyorum.” |
| Teşhis | Genellikle bir sorundur. Sorgu optimizasyonu veya index gerektirir. | Genellikle zararsızdır. Sistemin doğal akışıdır. |
| Müdahale | MAXDOP, CTFP veya İstatistik güncellemesi gerekir. | Çoğu zaman görmezden gelinmelidir (Benign wait). |
Neden CXCONSUMER Görürüz?
- Doğal Paralellik: Paralel bir planda her zaman bir “Control Thread” (Yönetici İş Parçacığı) bulunur. Bu yönetici, işçiler işini bitirene kadar bekler. Bu bekleme süresi CXCONSUMER olarak loglanır.
- Hızlı Üretim: Tüketici thread, veriyi üreticiden daha hızlı işliyorsa (veya üretici yavaşsa), tüketici sürekli “Sıradaki veri nerede?” diyerek beklemeye geçer.
- Sorgu Yapısı: ORDER BY, GROUP BY gibi operatörler içeren paralel sorgularda, verinin tamamlanıp birleştirilmesi aşamasında bu bekleme tipi kaçınılmazdır.
Çoğu performans uzmanı, sistemdeki darboğazı analiz ederken CXCONSUMER’ı hesaplamalara katmaz. Eğer toplam bekleme sürenizde CXCONSUMER çok yüksekse:
- Bu, SQL Server’ın paralelliği kullandığını ancak tüketicilerin (Consumer) üreticilerden (Producer) daha hızlı olduğunu gösterir.
- Eğer CXCONSUMER yüksek ama CXPACKET de yüksekse, asıl sorunu CXPACKET tarafında arayın (Eksik index, Data Skew).
- Verimsiz sorguları optimize etmek, paralel sorgularda MAXDOP ayarını düzenlemek, CPU yükünü azaltabilir.
- Eğer CPU kaynakları sıkça tükeniyorsa, daha güçlü işlemciler veya daha fazla işlemci çekirdeği eklemek faydalı olabilir.
- Analiz yaparken bu bekleme tipini filtreleyerek gerçek sorunları daha net görebilirsiniz:
SELECT wait_type, wait_time_ms
FROM sys.dm_os_wait_stats
WHERE wait_type NOT IN ('CXCONSUMER', 'SLEEP_TASK', 'BROKER_EVENT_HANDLER')
ORDER BY wait_time_ms DESC;
CX Consumer, paralel iş parçacıklarından biri işini tamamladıktan sonra diğer iş parçacıklarını beklerken ortaya çıkar. Genellikle “CX Packet” bekleme türü ile birlikte görülür. Yüksek CX Consumer beklemeleri, sorguların aşırı paralelleştirilmesi veya dengesiz iş yükü dağılımı nedeniyle oluşabilir. MAXDOP (Maximum Degree of Parallelism) ayarının optimize edilmesi veya Query Cost Threshold for Parallelism değerinin gözden geçirilmesi sorunu azaltabilir.
CXCONSUMER, SQL Server’ın paralel işlemlerdeki “bekleme kirliliğini” temizlemek için sunduğu bir lütuftur. Eğer bir doktorun stetoskopla sağlıklı bir kalbin atışını dinlemesi gibi düşünürsek; CXCONSUMER kalbin atış sesidir, CXPACKET ise kalpteki ritim bozukluğudur. Bizim odaklanmamız gereken ritim bozukluğudur.
Başka makalede görüşmek dileğiyle..
Anne babaya kaba davranmayın İsra-23
