HDInsight ve Azure Data Lake Storage 1. Nesil'de Storm için performans ayarlama kılavuzu

  • Makale

Azure Storm topolojisinin performansını ayarlarken dikkate alınması gereken faktörleri anlayın. Örneğin, spout'lar ve cıvatalar tarafından yapılan işin özelliklerini anlamak önemlidir (işin G/Ç veya bellek yoğunluklu olması fark etmeksizin). Bu makale, sık karşılaşılan sorunları giderme de dahil olmak üzere çeşitli performans ayarlama yönergelerini kapsar.

Önkoşullar

Topolojinin paralelliğini ayarlama

Data Lake Storage 1. Nesil gelen ve Data Lake Storage 1. Nesil gelen G/Ç'nin eşzamanlılığını artırarak performansı geliştirebilirsiniz. Storm topolojisinde paralelliği belirleyen bir dizi yapılandırma vardır:

  • Çalışan işlemlerinin sayısı (çalışanlar VM'ler arasında eşit olarak dağıtılır).
  • Spout yürütücü örneklerinin sayısı.
  • Bolt yürütücü örneklerinin sayısı.
  • Spout görevlerinin sayısı.
  • Cıvata görevlerinin sayısı.

Örneğin, 4 VM ve 4 çalışan işlemi, 32 spout yürütücüsü ve 32 spout görevi ve 256 bolt yürütücüsü ve 512 bolt görevi olan bir kümede aşağıdakileri göz önünde bulundurun:

Çalışan düğümü olan her gözetmen, tek bir çalışan Java sanal makinesi (JVM) işlemine sahiptir. Bu JVM işlemi 4 spout iş parçacığını ve 64 cıvata iş parçacıklarını yönetir. Her iş parçacığında görevler sıralı olarak çalıştırılır. Önceki yapılandırmada, her spout iş parçacığının bir görevi vardır ve her cıvata iş parçacığının iki görevi vardır.

Storm'da, ilgili çeşitli bileşenler ve bunların sahip olduğunuz paralellik düzeyini nasıl etkilediği şunlardır:

  • İşleri göndermek ve yönetmek için baş düğüm (Storm'da Nimbus olarak adlandırılır) kullanılır. Bu düğümlerin paralellik derecesi üzerinde hiçbir etkisi yoktur.
  • Gözetmen düğümleri. HDInsight'ta bu, çalışan düğümü Azure VM'sine karşılık gelir.
  • Çalışan görevleri, VM'lerde çalışan Storm işlemleridir. Her çalışan görevi bir JVM örneğine karşılık gelir. Storm, belirttiğiniz çalışan işlemlerinin sayısını çalışan düğümlerine mümkün olduğunca eşit bir şekilde dağıtır.
  • Spout ve bolt yürütücü örnekleri. Her yürütücü örneği, çalışanlar (JVM'ler) içinde çalışan bir iş parçacığına karşılık gelir.
  • Storm görevleri. Bunlar, bu iş parçacıklarının her biri tarafından çalıştırılacak mantıksal görevlerdir. Bu, paralellik düzeyini değiştirmez, bu nedenle yürütücü başına birden çok görev gerekip gerekmediğini değerlendirmeniz gerekir.

Data Lake Storage 1. Nesil'dan en iyi performansı elde edin

Data Lake Storage 1. Nesil ile çalışırken, aşağıdakileri yaparsanız en iyi performansı elde edersiniz:

  • Küçük eklerinizi daha büyük boyutlarda birleştirir (ideal olarak 4 MB).
  • Olabildiğince çok eşzamanlı istek yapın. Her cıvata iş parçacığı engelleme okumaları yaptığı için çekirdek başına 8-12 iş parçacığı aralığında bir yere sahip olmak istiyorsunuz. Bu, NIC ve CPU'nun iyi kullanılmasını sağlar. Daha büyük bir VM daha fazla eşzamanlı istek sağlar.

Örnek topoloji

D13v2 Azure VM'sine sahip sekiz çalışan düğümü kümeniz olduğunu varsayalım. Bu VM'nin sekiz çekirdeği vardır, bu nedenle sekiz çalışan düğümü arasında toplam 64 çekirdeğiniz vardır.

Diyelim ki çekirdek başına sekiz cıvata iş parçacığı yapıyoruz. 64 çekirdek verildiğinde toplam 512 cıvata yürütücü örneği (iş parçacığı) istediğimiz anlamına gelir. Bu örnekte VM başına bir JVM ile başladığımızı ve eşzamanlılık elde etmek için JVM içindeki iş parçacığı eşzamanlılığını kullandığımızı varsayalım. Bu, sekiz çalışan görevine (Azure VM başına bir tane) ve 512 cıvata yürütücüsüne ihtiyacımız olduğu anlamına gelir. Bu yapılandırma göz önünde bulundurulduğunda Storm, çalışanları çalışan düğümleri arasında eşit bir şekilde dağıtmayı (gözetmen düğümleri olarak da bilinir) dener ve her çalışan düğümüne bir JVM verir. Artık gözetmenler içinde Storm yürütücüleri gözetmenler arasında eşit bir şekilde dağıtmaya çalışır ve her gözetmene (yani JVM) her biri sekiz iş parçacığı verir.

Ek parametreleri ayarlama

Temel topolojiye sahip olduktan sonra, parametrelerden herhangi birini değiştirmek isteyip istemediğinizi düşünebilirsiniz:

  • Çalışan düğümü başına JVM sayısı. Bellekte barındırdığınız büyük bir veri yapınız (örneğin, arama tablosu) varsa, her JVM için ayrı bir kopya gerekir. Alternatif olarak, daha az JVM'niz varsa veri yapısını birçok iş parçacığında kullanabilirsiniz. Cıvatanın G/Ç'leri için JVM sayısı, bu JVM'lere eklenen iş parçacığı sayısı kadar fark etmez. Kolaylık olması için çalışan başına bir JVM kullanmak iyi bir fikirdir. Cıvatanızın ne yaptığına veya hangi uygulama işlemine ihtiyacınız olduğuna bağlı olarak, bu sayıyı değiştirmeniz gerekebilir.
  • Spout yürütücülerinin sayısı. Yukarıdaki örnekte Data Lake Storage 1. Nesil yazmak için cıvatalar kullanıldığı için, spout sayısı cıvata performansıyla doğrudan ilgili değildir. Ancak, spout'ta gerçekleşen işleme veya G/Ç miktarına bağlı olarak, en iyi performans için spout'ları ayarlamak iyi bir fikirdir. Cıvataları meşgul etmek için yeterli spout'lara sahip olduğunuzdan emin olun. Spout'ların çıkış hızları cıvataların aktarım hızıyla eşleşmelidir. Gerçek yapılandırma spout'a bağlıdır.
  • Görev sayısı. Her cıvata tek bir iş parçacığı olarak çalışır. Cıvata başına ek görevler ek eşzamanlılık sağlamaz. Tek fayda, tanımlama grubunuzu kabul etme sürecinizin cıvata yürütme sürenizin büyük bir kısmını almasıdır. Cıvatadan bir bildirim göndermeden önce birçok tanımlama grubunu daha büyük bir eklemede gruplandırmak iyi bir fikirdir. Bu nedenle çoğu durumda birden çok görev ek bir fayda sağlamaz.
  • Yerel veya karışık gruplandırma. Bu ayar etkinleştirildiğinde tanımlama kümeleri aynı çalışan işlemi içindeki cıvatalara gönderilir. Bu, işlemler arası iletişimi ve ağ çağrılarını azaltır. Bu, çoğu topoloji için önerilir.

Bu temel senaryo iyi bir başlangıç noktasıdır. En iyi performansı elde etmek için önceki parametreleri değiştirmek için kendi verilerinizle test edin.

Spout'unu ayarlama

Spout'un ayarlanması için aşağıdaki ayarları değiştirebilirsiniz.

  • Tanımlama grubu zaman aşımı: topology.message.timeout.secs. Bu ayar, iletinin başarısız olduğu kabul edilmeden önce tamamlanması ve onay alması için gereken süreyi belirler.

  • Çalışan işlemi başına en fazla bellek: worker.childopts. Bu ayar, Java çalışanlarına ek komut satırı parametreleri belirtmenizi sağlar. Burada en sık kullanılan ayar, bir JVM yığınına ayrılan en yüksek belleği belirleyen XmX ayarıdır.

  • Bekleyen en fazla spout: topology.max.spout.pending. Bu ayar, herhangi bir zamanda spout iş parçacığı başına uçabilecek tanımlama grubu sayısını (topolojideki tüm düğümlerde henüz kabul edilmemektedir) belirler.

    Yapılacak iyi bir hesaplama, tanımlama listelerinizin her birinin boyutunu tahmin etmektir. Ardından bir spout iş parçacığının ne kadar belleğe sahip olduğunu öğrenin. Bir iş parçacığına ayrılan ve bu değere bölünen toplam bellek, bekleyen maksimum spout parametresi için size üst sınır vermelidir.

Cıvatayı ayarlama

Data Lake Storage 1. Nesil'a yazarken, boyut eşitleme ilkesini (istemci tarafındaki arabellek) 4 MB olarak ayarlayın. Daha sonra yalnızca arabellek boyutu bu değerde olduğunda bir boşaltma veya hsync() gerçekleştirilir. Açıkça hsync() gerçekleştirmediğiniz sürece, çalışan VM'sinde Data Lake Storage 1. Nesil sürücüsü bu arabelleğe almayı otomatik olarak yapar.

Varsayılan Data Lake Storage 1. Nesil Storm bolt, bu parametreyi ayarlamak için kullanılabilecek bir boyut eşitleme ilkesi parametresine (fileBufferSize) sahiptir.

G/Ç yoğunluklu topolojilerde her cıvata iş parçacığının kendi dosyasına yazılması ve bir dosya döndürme ilkesi (fileRotationSize) ayarlanması iyi bir fikirdir. Dosya belirli bir boyuta ulaştığında akış otomatik olarak boşaltılır ve yeni bir dosyaya yazılır. Döndürme için önerilen dosya boyutu 1 GB'tır.

Tanımlama grubu verilerini işleme

Storm'da bir spout, cıvata tarafından açıkça onaylanana kadar bir tanımlama grubuna dayanır. Tanımlama grubu cıvata tarafından okunduysa ancak henüz onaylanmadıysa, spout arka uçta Data Lake Storage 1. Nesil kalıcı olmayabilir. Bir tanımlama grubu onaylandıktan sonra, spout bolt tarafından kalıcılık garanti edilebilir ve daha sonra kaynak verileri okuduğu kaynaktan silebilir.

Data Lake Storage 1. Nesil en iyi performans için cıvata arabelleği 4 MB tanımlama grubu verisine sahip olmalıdır. Ardından Data Lake Storage 1. Nesil arka ucuna 4 MB yazma olarak yazın. Veriler depoya başarıyla yazıldıktan sonra (hflush() çağrısı yaparak), bolt verileri spout'a geri kabul edebilir. Burada sağlanan örnek cıvatanın yaptığı budur. Hflush() çağrısı yapılmadan ve tanımlama kümeleri kabul etmeden önce daha fazla sayıda tanımlama grubu tutmak da kabul edilebilir. Ancak bu, spout'un tutması gereken uçuş tanımlama grubu sayısını artırır ve bu nedenle JVM başına gereken bellek miktarını artırır.

Not

Uygulamalar, performans dışı nedenlerden dolayı tanımlama listelerini daha sık (4 MB'tan küçük veri boyutlarında) kabul etme gereksinimine sahip olabilir. Ancak bu, depolama arka ucuna G/Ç aktarım hızını etkileyebilir. Bu dengeyi cıvatanın G/Ç performansına karşı dikkatle tartın.

Gelen tanımlama grubu oranı yüksek değilse, dolayısıyla 4 MB arabelleğin doldurulması uzun sürüyorsa, bunu şu şekilde azaltmayı göz önünde bulundurun:

  • Cıvata sayısını azaltarak doldurulacak arabellek sayısı azalır.
  • Her x boşaltma veya y milisaniyede bir hflush() tetiklendiği ve şimdiye kadar birikmiş demetlerin geri alındığı zamana dayalı veya sayı tabanlı bir ilkeye sahip olmak.

Bu durumda aktarım hızı daha düşüktür, ancak olayların yavaş olması durumunda en büyük hedef en yüksek aktarım hızı değildir. Bu hafifletmeler, bir tanımlama kümesinin mağazaya akması için gereken toplam süreyi azaltmanıza yardımcı olur. Düşük olay hızıyla bile gerçek zamanlı bir işlem hattı istiyorsanız bu önemli olabilir. Ayrıca, gelen tanımlama grubu hızınız düşükse, topology.message.timeout_secs parametresini ayarlamanız gerektiğini unutmayın; böylece tanımlama grupları arabelleğe alınıp işlenirken zaman aşımına girmez.

Storm'da topolojinizi izleme

Topolojiniz çalışırken Storm kullanıcı arabiriminde bunu izleyebilirsiniz. Göz atacak ana parametreler şunlardır:

  • Toplam işlem yürütme gecikmesi. Bu, bir tanımlama düzeninin spout tarafından yayılması, cıvata tarafından işlenmesi ve kabul edilmesi için geçen ortalama süredir.

  • Toplam bolt işlemi gecikme süresi. Bu, tanımlama grubu tarafından bir bildirim alana kadar cıvatada harcanan ortalama süredir.

  • Toplam bolt yürütme gecikmesi. Bu, yürütme yönteminde bolt tarafından harcanan ortalama süredir.

  • Hata sayısı. Bu, zaman aşımına uğramadan önce tam olarak işlenemeyen tanımlama grubu sayısını ifade eder.

  • Kapasite. Bu, sisteminizin ne kadar meşgul olduğunu gösteren bir ölçüdür. Bu sayı 1 ise, cıvatalarınız olabildiğince hızlı çalışıyor. 1'den küçükse paralelliği artırın. 1'den büyükse paralelliği azaltın.

Yaygın sorunları giderme

Aşağıda bazı yaygın sorun giderme senaryoları yer alır.

  • Birçok tanımlama grubu zaman aşımına uğradı. Performans sorununun nerede olduğunu belirlemek için topolojideki her düğüme bakın. Bunun en yaygın nedeni cıvataların spout'lara ayak uyduramamasıdır. Bu, işlenmeyi beklerken iç arabelleklerin tıkanmasına neden olur. Zaman aşımı değerini artırmayı veya bekleyen maksimum spout değerini azaltmayı göz önünde bulundurun.

  • Toplam işlem yürütme gecikme süresi yüksektir, ancak düşük bolt işlem gecikme süresi vardır. Bu durumda, tanımlama demetlerinin yeterince hızlı kabul edilmemesi mümkündür. Yeterli sayıda onaylayan olup olmadığını denetleyin. Bir diğer olasılık, cıvataların bunları işlemeye başlaması için kuyrukta çok uzun süre beklemeleridir. Bekleyen maksimum spout değerini azaltın.

  • Yüksek cıvata yürütme gecikmesi vardır. Bu, cıvatanızın execute() yönteminin çok uzun sürdüğü anlamına gelir. Kodu iyileştirin veya yazma boyutlarına ve boşaltma davranışına bakın.

Data Lake Storage 1. Nesil azaltma

Data Lake Storage 1. Nesil tarafından sağlanan bant genişliği sınırlarına ulaşmanız durumunda görev hataları görebilirsiniz. Azaltma hataları için görev günlüklerini denetleyin. Kapsayıcı boyutunu artırarak paralelliği azaltabilirsiniz.

Kısıtlama alıp almadığınızdan emin olmak için istemci tarafında hata ayıklama günlüğünü etkinleştirin:

  1. Ambari>Storm>Yapılandırması>Gelişmiş storm-worker-log4j içinderoot level="info" değerini root level="debug"> olarak değiştirin<.<> Yapılandırmanın etkili olması için tüm düğümleri/hizmeti yeniden başlatın.
  2. Data Lake Storage 1. Nesil azaltma özel durumları için çalışan düğümlerindeki Storm topoloji günlüklerini izleyin (/var/log/storm/storm/<worker-artifacts/TopologyName>/<port>/worker.log).

Sonraki adımlar

Storm için ek performans ayarlamaya bu blogda başvurabilirsiniz.

Çalıştırmak için ek bir örnek için GitHub'da buna bakın.