Belirtiler panolardan değil kullanıcılardan gelir: raporlar dönüp durur, görseller zaman aşımına uğrar, dışa aktarımlar kapasite hatasıyla başarısız olur. Suç rapora atılır, ama sebep kapasitedir — üzerindeki bir şey SKU’nun sağladığından fazla işlem gücü harcamıştır ve Fabric kendini savunmaya başlamıştır. Bu savunma throttling’dir ve gerçekten bilmeye değer, belgelenmiş bir mekaniği vardır.
Smoothing ve burndown
Fabric bir işlemi çalıştığı anda faturalandırmaz. İnteraktif işlemler kısa bir pencereye (dakikalar), arka plan işlemleri — yenilemeler, dataflow’lar, notebook’lar — 24 saate yayılır. Yayılmış tüketim kapasitenin CU bütçesini aştığında, fazlası gelecekteki kapasiteden ödünç alınır (carryforward) ve kapasite yeniden sağlıklı olmadan önce geri ödenmesi — yakılması — gerekir. Throttling’in şiddeti, gelecekteki kapasitenin ne kadarını çoktan harcadığınızın bir fonksiyonudur.
Throttling merdiveni
- 10 dakikadan az gelecek kapasite tüketildiyse: aşım koruması — throttling yok, borç yalnızca yakılır.
- 10 dakika ile 1 saat arası: Interactive Delay — kullanıcıya dönük sorgular yapay olarak geciktirilir (yaklaşık 20 saniye); raporlar ağırlaşır.
- 1 ile 24 saat arası: Interactive Rejection — kullanıcı sorguları doğrudan reddedilir; arka plan işleri çalışmayı sürdürür.
- 24 saatin ötesinde: Background Rejection — yenilemeler dahil her şey reddedilir. Kapasite fiilen kapanmıştır.
Suçluyu bulmak
Teşhis bir sıralama işidir: throttling penceresi çevresinde öğe ve işlem bazında CU tüketimi, interaktif/arka plan ayrımıyla. Olağan suçlular, sıklık sırasıyla: aynı saate yığılmış zamanlanmış yenilemeler, kontrolden çıkmış bir dataflow veya notebook, tam yükleme yapan gereğinden büyük tek bir semantic model ve gerçek interaktif yük artışı. Capacity Metrics uygulaması bu ayrıntıyı tutar — yaklaşık 14 gün; dünkü olay için yeterli, “bu her ay sonu tekrarlanıyor” için işe yaramaz.
Çözüm kalıpları
- Yenileme zamanlamalarını yayın — 08:00 yığılması en yaygın kendi kendine açılan throttling’dir.
- Ağır tam yenilemeleri artımlıya çevirin.
- Kimse için yenilenen zombi model’leri emekliye ayırın.
- Geliştirme/test ve ağır mühendislik iş yüklerini raporlama kapasitesinden ayırın.
- Ancak bundan sonra bir sonraki SKU’yu düşünün — faturayı ikiye katlamadan önce FinOps rehberine bakın.
Öğe bazlı geçmiş, işe yarayacak kadar uzun
PGR Sonar zaman noktası düzeyinde kapasite tüketimini öğe ve işlem bazında uzun vadeli geçmiş olarak saklar; böylece throttling incelemesi aylar boyunca çalışır: geçmişteki herhangi bir olayın çevresinde kullanım oranının nasıl göründüğü, ay ay hangi öğelerin baskın olduğu ve uygulanan çözümün gerçekten tutup tutmadığı. Kapasite Teşhisi aynı veriyi somut önerilere çevirir — bir sonraki olaydan önce yeniden zamanlanacak veya iyileştirilecek model’ler, dataflow’lar ve notebook’lar.