Ölçümleri ve boyutları kullanarak Stream Analytics iş performansını analiz etme
Azure Stream Analytics işinin durumunu anlamak için işin ölçümlerini ve boyutlarını nasıl kullanacağınızı bilmek önemlidir. İlgilendiğiniz ölçümleri ve boyutları almak için Azure portal, Visual Studio Code Stream Analytics uzantısını veya SDK'yı kullanabilirsiniz.
Bu makalede, Azure portal aracılığıyla bir işin performansını analiz etmek için Stream Analytics iş ölçümlerinin ve boyutlarının nasıl kullanılacağı gösterilmektedir.
Filigran gecikmesi ve gerilogged giriş olayları, Stream Analytics işinizin performansını belirlemeye yönelik ana ölçümlerdir. İşinizin eşik gecikmesi sürekli artıyorsa ve giriş olayları geri yer alıyorsa, işiniz giriş olaylarının hızına ayak uyduramaz ve zamanında çıkış üretemez.
Başlangıç noktası olarak Filigran Gecikmesi ölçüm verileri aracılığıyla bir işin performansını analiz etmek için birkaç örneğe göz atalım.
Belirli bir bölüm için giriş olmaması iş filigranı gecikmesini artırır
Utanç verici derecede paralel işinizin eşik gecikmesi sürekli artıyorsa Ölçümler'e gidin. Ardından, kök nedenin giriş kaynağınızın bazı bölümlerinde veri eksikliği olup olmadığını öğrenmek için şu adımları kullanın:
Hangi bölümün artan filigran gecikmesine sahip olduğunu denetleyin. Filigran Gecikmesi ölçümünü seçin ve Bölüm Kimliği boyutuna göre bölün. Aşağıdaki örnekte, bölüm 465'te filigran gecikmesi yüksek.
Bu bölüm için herhangi bir giriş verisi eksik olup olmadığını denetleyin. Giriş Olayları ölçümünü seçin ve bu bölüm kimliğine göre filtreleyin.
Başka hangi işlemleri gerçekleştirebilirsiniz?
Bu bölüme hiçbir giriş olayı akmadığı için bu bölümün eşik gecikmesi artıyor. İşinizin geç varışlar için tolerans penceresi birkaç saatse ve bölüme hiçbir giriş verisi akmazsa, geç varış penceresine ulaşılana kadar bu bölüm için filigran gecikmesinin artmaya devam etmesi beklenir.
Örneğin, geç varış pencereniz 6 saatse ve giriş verileri giriş bölümü 1'e akmıyorsa, çıkış bölümü 1 için filigran gecikmesi 6 saate ulaşana kadar artar. Giriş kaynağınızın beklendiği gibi veri üretip üretmediğini de kontrol edebilirsiniz.
Giriş verileri dengesizliği filigran gecikmelerine neden oluyor
Önceki örnekte belirtildiği gibi, utanç verici derecede paralel işinizde yüksek filigran gecikmesi olduğunda, yapılacak ilk şey Filigran Gecikmesi ölçümünü Bölüm Kimliği boyutuna bölmektir. Daha sonra tüm bölümlerin filigran gecikmesinin yüksek mi yoksa yalnızca birkaçının mı olduğunu belirleyebilirsiniz.
Aşağıdaki örnekte, 0 ve 1 bölümleri diğer sekiz bölümden daha yüksek filigran gecikmesine (yaklaşık 20-30 saniye) sahiptir. Diğer bölümlerin filigran gecikmeleri her zaman yaklaşık 8 ile 10 saniye arasındadır.
Bölüm Kimliğine göre bölünmüş Giriş Olayları ölçümüyle tüm bu bölümler için giriş verilerinin nasıl göründüğünü kontrol edelim:
Başka hangi işlemleri gerçekleştirebilirsiniz?
Örnekte gösterildiği gibi, filigran gecikmesi yüksek olan bölümler (0 ve 1) diğer bölümlerden önemli ölçüde daha fazla giriş verisi alır. Buna veri dengesizliği diyoruz. Aşağıdaki ekran görüntüsünde gösterildiği gibi, veri dengesizliği olan bölümleri işleyen akış düğümlerinin diğerlerinden daha fazla CPU ve bellek kaynağı tüketmesi gerekir.
Daha yüksek veri dengesizliği olan bölümleri işleyen akış düğümleri daha yüksek CPU ve/veya akış birimi (SU) kullanımı gösterir. Bu kullanım işin performansını etkiler ve filigran gecikmesini artırır. Bunu azaltmak için giriş verilerinizi daha eşit bir şekilde yeniden bölümlemelisiniz.
Bu sorunun hatalarını fiziksel iş diyagramıyla da ayıklayabilirsiniz. Bkz. Fiziksel iş diyagramı: Eşit olmayan dağıtılmış giriş olaylarını (veri dengesizliği) tanımlama.
Aşırı yüklenmiş CPU veya bellek eşik gecikmeyi artırır
Utanç verici derecede paralel bir işin filigran gecikmesi arttığında, bu yalnızca bir veya birkaç bölümde değil, tüm bölümlerde gerçekleşebilir. İşinizin bu davaya dahil olduğunu nasıl onaylarsınız?
Filigran Gecikmesi ölçümünü Bölüm Kimliği'ne bölün. Örnek:
Her bölüm için giriş verilerinde veri dengesizliği olup olmadığını onaylamak için Giriş Olayları ölçümünü Bölüm Kimliğine bölün.
Tüm akış düğümlerindeki kullanımın çok yüksek olup olmadığını görmek için CPU ve SU kullanımını denetleyin.
Tüm akış düğümlerinde CPU ve SU kullanımı çok yüksekse (yüzde 80'den fazla), bu işin her akış düğümünde büyük miktarda veri işlendiği sonucuna varabilirsiniz.
Giriş Olayları ölçümünü denetleyerek bir akış düğümüne kaç bölüm ayrıldığını daha fazla kontrol edebilirsiniz. Düğüm Adı boyutuyla akış düğümü kimliğine göre filtreleyin ve Bölüm Kimliğine göre bölün.
Yukarıdaki ekran görüntüsünde dört bölümün akış düğümü kaynağının yaklaşık yüzde 90 ile 100'ünü kaplayan bir akış düğümüne ayrıldığı gösterilmektedir. Akış düğümlerinin geri kalanını denetlemek için benzer bir yaklaşım kullanarak bunların da dört bölümden verileri işlediğini onaylayabilirsiniz.
Başka hangi işlemleri gerçekleştirebilirsiniz?
Her akış düğümü için giriş verilerini azaltmak için her akış düğümü için bölüm sayısını azaltmak isteyebilirsiniz. Bunu başarmak için SU'ları iki katına çıkararak her akış düğümlerinin iki bölümden verileri işlemesini sağlayabilirsiniz. Ya da SU'ları dört katına çıkararak her akış düğümlerinin bir bölümdeki verileri işlemesini sağlayabilirsiniz. SU ataması ile akış düğümü sayısı arasındaki ilişki hakkında bilgi için bkz. Akış birimlerini anlama ve ayarlama.
Bir akış düğümü bir bölümdeki verileri işlerken filigran gecikmesi artmaya devam ediyorsa ne yapmalısınız? Her bölümdeki veri miktarını azaltmak için girişinizi daha fazla bölümle yeniden bölümleme. Ayrıntılar için bkz. Azure Stream Analytics işlerini iyileştirmek için yeniden bölümleme kullanma.
Bu sorunun hatalarını fiziksel iş diyagramıyla da ayıklayabilirsiniz. Bkz. Fiziksel iş diyagramı: Aşırı yüklenmiş CPU veya belleğin nedenini belirleme.