Sdílet prostřednictvím

Pokyny k ladění výkonu pro Storm ve službě HDInsight a Azure Data Lake Storage Gen1

  • Článek

Seznamte se s faktory, které byste měli vzít v úvahu při ladění výkonu topologie Azure Storm. Je například důležité porozumět charakteristikám práce, kterou provádějí spouty a bolty (bez ohledu na to, jestli je práce náročná na vstupně-výstupní operace nebo na paměť). Tento článek popisuje celou řadu pokynů pro ladění výkonu, včetně řešení běžných problémů.

Požadavky

Ladění paralelismu topologie

Výkon můžete zvýšit zvýšením souběžnosti vstupně-výstupních operací do Data Lake Storage Gen1 a z Data Lake Storage Gen1. Topologie Storm má sadu konfigurací, které určují paralelismus:

  • Počet pracovních procesů (pracovní procesy jsou rovnoměrně rozdělené mezi virtuální počítače)
  • Počet instancí exekutoru spout
  • Počet instancí exekutoru bolt.
  • Počet úloh spout
  • Počet úloh boltu

Například v clusteru se 4 virtuálními počítači a 4 pracovními procesy, 32 exekutory spout a 32 úkoly spout a 256 exekutorů bolt a 512 úloh bolt zvažte následující:

Každý nadřízený, což je pracovní uzel, má jeden pracovní proces prostředí Java Virtual Machine (JVM). Tento proces JVM spravuje 4 vlákna spout a 64 vláken boltů. V každém vlákně se úlohy spouští postupně. V předchozí konfiguraci má každé vlákno spout jeden úkol a každé vlákno boltu má dvě úlohy.

V Stormu jsou uvedené různé komponenty a jejich vliv na úroveň paralelismu, kterou máte:

  • Hlavní uzel (v Stormu označovaný jako Nimbus) slouží k odesílání a správě úloh. Tyto uzly nemají žádný vliv na stupeň paralelismu.
  • Uzly správce. Ve službě HDInsight to odpovídá virtuálnímu počítači Azure pracovního uzlu.
  • Pracovní úkoly jsou procesy Storm spuštěné na virtuálních počítačích. Každý úkol pracovního procesu odpovídá instanci JVM. Storm distribuuje počet pracovních procesů, které zadáte, do pracovních uzlů co nejrovnoměrněji.
  • Instance exekutoru Spout a bolt. Každá instance exekutoru odpovídá vláknu spuštěného v rámci pracovních procesů (JVM).
  • Úkoly Storm. Jedná se o logické úlohy, které spouští každé z těchto vláken. Úroveň paralelismu se tím nezmění, takže byste měli vyhodnotit, jestli potřebujete více úloh na exekutor nebo ne.

Získejte nejlepší výkon z Data Lake Storage Gen1

Při práci s Data Lake Storage Gen1 získáte nejlepší výkon v následujících případech:

  • Svá malá připojení sloučit do větších velikostí (ideálně 4 MB).
  • Proveďte co nejvíce souběžných požadavků. Vzhledem k tomu, že každé vlákno boltu provádí blokující čtení, chcete mít někde v rozsahu 8 až 12 vláken na jádro. Díky tomu zůstane síťová karta a procesor dobře využité. Větší virtuální počítač umožňuje více souběžných požadavků.

Příklad topologie

Předpokládejme, že máte cluster s osmi pracovními uzly a virtuálním počítačem Azure D13v2. Tento virtuální počítač má osm jader, takže z osmi pracovních uzlů máte celkem 64 jader.

Řekněme, že pro každé jádro děláme osm vláken šroubů. Vzhledem k 64 jádrům to znamená, že chceme celkem 512 instancí exekutoru bolt (to znamená vláken). V tomto případě řekněme, že začneme s jedním JVM na virtuální počítač a k dosažení souběžnosti použijeme hlavně souběžnost vláken v prostředí JVM. To znamená, že potřebujeme osm úloh pracovních procesů (jeden na virtuální počítač Azure) a 512 exekutorů bolt. Vzhledem k této konfiguraci se Storm pokusí distribuovat pracovní procesy rovnoměrně mezi pracovní uzly (označované také jako uzly nadřízeného), přičemž každému pracovnímu uzlu přidělí jeden počítač JVM. Nyní se Storm v rámci nadřízených snaží distribuovat exekutory rovnoměrně mezi nadřízené a každému nadřízenému (tj. JVM) dává osm vláken.

Ladění dalších parametrů

Jakmile budete mít základní topologii, můžete zvážit, jestli chcete některý z parametrů upravit:

  • Počet počítačů JVM na pracovní uzel Pokud máte velkou datovou strukturu (například vyhledávací tabulku), kterou hostujete v paměti, každý počítač JVM vyžaduje samostatnou kopii. Případně můžete datovou strukturu použít napříč mnoha vlákny, pokud máte méně prostředí JVM. U vstupně-výstupních operací boltu není počet prostředí JVM tak velký rozdíl jako počet vláken přidaných do těchto prostředí JVM. Pro zjednodušení je vhodné mít pro každého pracovníka jeden JVM. V závislosti na tom, co váš bolt dělá nebo jaké zpracování aplikace vyžadujete, ale možná budete muset toto číslo změnit.
  • Počet exekutorů spout. Vzhledem k tomu, že předchozí příklad používá bolty pro zápis do Data Lake Storage Gen1, počet spoutů není přímo relevantní pro výkon boltu. V závislosti na množství zpracování nebo vstupně-výstupních operací probíhajících ve spoutu je ale vhodné vyladit spouty pro zajištění nejlepšího výkonu. Ujistěte se, že máte dostatek spoutů, abyste mohli udržovat šrouby zaneprázdněné. Výstupní rychlosti spoutů by měly odpovídat propustnosti boltů. Skutečná konfigurace závisí na spoutu.
  • Počet úkolů Každý bolt běží jako jedno vlákno. Další úlohy na jeden bolt neposkytují žádnou další souběžnost. Přínosné jsou pouze tehdy, když proces potvrzení řazené kolekce členů trvá velkou část doby provádění boltu. Před odesláním potvrzení z boltu je vhodné seskupit mnoho řazených kolekcí členů do většího připojení. Ve většině případů tedy více úkolů neposkytuje žádnou další výhodu.
  • Místní seskupení nebo náhodné seskupení Pokud je toto nastavení povoleno, jsou řazené kolekce členů odesílány do boltů v rámci stejného pracovního procesu. Tím se omezí meziprocesová komunikace a síťová volání. Tento postup se doporučuje pro většinu topologií.

Tento základní scénář je dobrým výchozím bodem. Otestujte s vlastními daty a upravte předchozí parametry, abyste dosáhli optimálního výkonu.

Ladění spoutu

Pokud chcete vyladit spout, můžete upravit následující nastavení.

  • Časový limit řazené kolekce členů: topology.message.timeout.secs. Toto nastavení určuje dobu, po kterou zpráva trvá dokončení a přijetí potvrzení, než se zpráva považuje za neúspěšnou.

  • Maximální paměť na pracovní proces: worker.childopts. Toto nastavení umožňuje zadat další parametry příkazového řádku pro pracovní procesy Javy. Nejčastěji používané nastavení je XmX, které určuje maximální paměť přidělenou haldě JVM.

  • Maximální počet čekajících spout: topology.max.spout.pending. Toto nastavení určuje počet řazených kolekcí členů, které lze kdykoli spustit (zatím nejsou potvrzeny na všech uzlech v topologii) na vlákno spout.

    Dobrým výpočtem je odhadnout velikost jednotlivých řazených kolekcí členů. Pak zjistěte, kolik paměti má jedno vlákno spout. Celková paměť přidělená vláknu vydělená touto hodnotou by měla poskytnout horní mez parametru max spout pending.

Ladění boltu

Při psaní do Data Lake Storage Gen1 nastavte zásadu synchronizace velikosti (vyrovnávací paměť na straně klienta) na 4 MB. Vyprazdňování nebo hsync() se pak provede pouze v případě, že velikost vyrovnávací paměti je na této hodnotě. Ovladač Data Lake Storage Gen1 na pracovním virtuálním počítači provádí toto ukládání do vyrovnávací paměti automaticky, pokud explicitně neprovedete hsync().

Výchozí Data Lake Storage Gen1 Storm bolt má parametr zásady synchronizace velikosti (fileBufferSize), který lze použít k ladění tohoto parametru.

U topologií náročných na vstupně-výstupní operace je vhodné nechat každé vlákno boltu zapisovat do vlastního souboru a nastavit zásady obměně souborů (fileRotationSize). Když soubor dosáhne určité velikosti, datový proud se automaticky vyprázdní a do souboru se zapíše nový soubor. Doporučená velikost souboru pro otáčení je 1 GB.

Zpracování dat řazené kolekce členů

V Stormu se spout drží na řazené kolekci členů, dokud ho bolt explicitně nepotvrdí. Pokud bolt načetl řazenou kolekci členů, ale ještě nebyla potvrzena, je možné, že se spout nezachoval do Data Lake Storage Gen1 back-endu. Po potvrzení řazené kolekce členů může bolt zaručit stálost řazené kolekce členů a pak může odstranit zdrojová data z jakéhokoli zdroje, ze něhož čte.

Nejlepšího výkonu na Data Lake Storage Gen1 dosáhnete, když bude mít vyrovnávací paměť boltu 4 MB dat řazené kolekce členů. Potom zapište do back-endu Data Lake Storage Gen1 jako jeden zápis o rozměrech 4 MB. Po úspěšném zápisu dat do úložiště (voláním hflush()) může bolt potvrdit data zpět do spout. To dělá příklad boltu, který jste zde zadali. Je také přijatelné mít větší počet řazených kolekcí členů před voláním hflush() a potvrzením řazených kolekcí členů. Tím se ale zvyšuje počet řazených kolekcí členů za letu, které musí spout uchovávat, a tím se zvyšuje množství paměti vyžadované na prostředí JVM.

Poznámka

Aplikace můžou mít požadavek na častější potvrzení řazených kolekcí členů (s velikostí dat menší než 4 MB) z jiných důvodů, než je výkon. To ale může ovlivnit propustnost vstupně-výstupních operací do back-endu úložiště. Pečlivě zvažte tento kompromis proti výkonu vstupně-výstupních operací boltu.

Pokud příchozí frekvence řazených kolekcí členů není vysoká, takže zaplnění 4 MB vyrovnávací paměti trvá dlouho, zvažte zmírnění tohoto rizika:

  • Snížení počtu šroubů, aby bylo potřeba vyplnit méně vyrovnávacích pamětí.
  • Zásady založené na čase nebo počtu, kdy se hflush() aktivuje každých x vyprázdnění nebo milisekund a doposud shromážděné řazené kolekce členů se vrátí zpět.

Propustnost je v tomto případě nižší, ale s pomalým tempem událostí není maximální propustnost stejně největším cílem. Tato omezení rizik vám pomůžou zkrátit celkovou dobu potřebnou k průchodu řazené kolekce členů do úložiště. To může být důležité, pokud chcete kanál v reálném čase i s nízkou frekvencí událostí. Všimněte si také, že pokud je příchozí frekvence řazených kolekcí členů nízká, měli byste upravit parametr topology.message.timeout_secs tak, aby během ukládání do vyrovnávací paměti nebo zpracování nevypadal časový limit řazených kolekcí členů.

Monitorování topologie v Stormu

Zatímco je topologie spuštěná, můžete ji monitorovat v uživatelském rozhraní Storm. Tady jsou hlavní parametry, na které je potřeba se podívat:

  • Celková latence provádění procesu Jedná se o průměrnou dobu, po kterou jedna řazená kolekce členů vygeneruje spout, zpracuje bolt a potvrdí.

  • Celková latence procesu boltu Jedná se o průměrnou dobu strávenou řazenou kolekcí členů u boltu, dokud neobdrží potvrzení.

  • Celková latence spuštění boltu Toto je průměrná doba strávená boltem v metodě execute.

  • Počet selhání To odkazuje na počet řazených kolekcí členů, které se nepodařilo plně zpracovat před vypršením jejich časového limitu.

  • Kapacita. Jedná se o míru zaneprázdnění systému. Pokud je toto číslo 1, fungují šrouby tak rychle, jak můžou. Pokud je menší než 1, zvyšte paralelismus. Pokud je větší než 1, snižte paralelismus.

Řešení běžných problémů

Tady je několik běžných scénářů řešení potíží.

  • U řady řazených kolekcí členů dochází k vypršení časového limitu. Podívejte se na jednotlivé uzly v topologii a zjistěte, kde je kritický bod. Nejčastějším důvodem je, že šrouby nejsou schopné držet krok s výplachy. To vede k zahltávání vnitřních vyrovnávacích pamětí při čekání na zpracování řazených kolekcí členů. Zvažte zvýšení hodnoty časového limitu nebo snížení maximálního počtu čekajících spoutů.

  • Existuje vysoká celková latence provádění procesu, ale nízká latence procesu bolt. V takovém případě je možné, že řazené kolekce členů nejsou potvrzeny dostatečně rychle. Zkontrolujte, že existuje dostatečný počet potvrzení. Další možností je, že čekají ve frontě příliš dlouho, než je začnou zpracovávat bolty. Snižte maximální počet nevyřízených spoutů.

  • Dochází k vysoké latenci provádění boltů. To znamená, že metoda execute() vašeho boltu trvá příliš dlouho. Optimalizujte kód nebo se podívejte na velikosti zápisu a chování vyprázdnění.

Data Lake Storage Gen1 omezování

Pokud dosáhnete limitů šířky pásma poskytovaných Data Lake Storage Gen1, může dojít k selhání úloh. V protokolech úloh zkontrolujte chyby omezování. Paralelismus můžete snížit zvětšením velikosti kontejneru.

Pokud chcete zkontrolovat, jestli dochází k omezování, povolte protokolování ladění na straně klienta:

  1. V Ambari>Storm>Config>Advanced storm-worker-log4j změňte <root level="info"> na <root level="debug">. Restartujte všechny uzly nebo službu, aby se konfigurace projevila.
  2. Monitorujte protokoly topologie Storm na pracovních uzlech (v části /var/log/storm/worker-artifacts/<TopologyName>/<port>/worker.log) a vyhledejte výjimky Data Lake Storage Gen1 omezování.

Další kroky

Další ladění výkonu pro Storm najdete v tomto blogu.

Další příklad ke spuštění najdete v tomto příkladu na GitHubu.