Ö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ı kullanmayı bilmek önemlidir. İlgilendiğiniz ölçümleri ve boyutları almak için Azure portalını, 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 filigran gecikmesi sürekli olarak artıyorsa ve giriş olayları geri yer alıyorsa, işiniz giriş olaylarının hızına ayak uyduramaz ve zamanında çıkışlar ü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 filigran gecikmesi sürekli artıyorsa Ölçümler'e gidin. Ardından, kök nedeninin 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 ne gibi eylemler gerçekleştirebilirsiniz?
Bu bölüme hiçbir giriş olayı akmadığı için bu bölüm için filigran gecikmesi artıyor. İşinizin geç varışlar için tolerans penceresi birkaç saatse ve bölüme hiçbir giriş verisi akmazsa, bu bölüm için filigran gecikmesinin geç varış penceresine ulaşılana kadar 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 yüksek filigran gecikmelerine neden oluyor
Önceki örnekte belirtildiği gibi, utanç verici derecede paralel işinizde yüksek filigran gecikmesi olduğunda, yapmanız gereken 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ümlerinin filigran gecikmesi (yaklaşık 20-30 saniye) diğer sekiz bölümden daha yüksektir. 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ü denetleyelim:
Başka ne gibi eylemler 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 ile 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 filigran 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 düştüğünü nasıl onaylayabilirsiniz?
Filigran Gecikmesi ölçümünü Bölüm Kimliğine göre bölün. Örneğin:
Giriş verilerinde her bölüm için veri dengesizliği olup olmadığını onaylamak için Giriş Olayları ölçümünü Bölüm Kimliğine göre 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, akış düğümü kaynağının yaklaşık yüzde 90 ile 100'ünü kaplayan bir akış düğümüne dört bölüm ayrıldığı gösterilmektedir. Akış düğümlerinin geri kalanını denetlemek için benzer bir yaklaşım kullanarak bunların dört bölümden verileri de işlediğini onaylayabilirsiniz.
Başka ne gibi eylemler 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 her akış düğümlerinin bir bölümdeki verileri işlemesini sağlamak için SU'ları dört katına çıkarabilirsiniz. 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.