Delen via

Richtlijnen voor het afstemmen van prestaties voor Storm in HDInsight en Azure Data Lake Storage Gen1

  • Artikel

Inzicht in de factoren waarmee rekening moet worden gehouden bij het afstemmen van de prestaties van een Azure Storm-topologie. Het is bijvoorbeeld belangrijk om de kenmerken te begrijpen van het werk dat door de spouts en de bouten wordt uitgevoerd (ongeacht of het werk I/O of geheugenintensief is). In dit artikel wordt een reeks richtlijnen voor het afstemmen van prestaties besproken, waaronder het oplossen van veelvoorkomende problemen.

Vereisten

De parallelle uitvoering van de topologie afstemmen

Mogelijk kunt u de prestaties verbeteren door de gelijktijdigheid van de I/O van en naar Data Lake Storage Gen1 te vergroten. Een Storm-topologie heeft een set configuraties die de parallelle uitvoering bepalen:

  • Aantal werkprocessen (de werkrollen zijn gelijkmatig verdeeld over de VM's).
  • Aantal exemplaren van spout-uitvoerders.
  • Aantal boltexemplaren.
  • Aantal spout-taken.
  • Aantal bolttaken.

In een cluster met 4 VM's en 4 werkprocessen, 32 spout-uitvoerders en 32 uitlooptaken, en 256 boltexecutors en 512 bolttaken, kunt u het volgende overwegen:

Elke supervisor, een werkknooppunt, heeft één JVM-proces (java virtual machine). Dit JVM-proces beheert 4 spout-schroefdraad en 64 bouten. Binnen elke thread worden taken opeenvolgend uitgevoerd. Met de voorgaande configuratie heeft elke spout-thread één taak en heeft elke boutdraad twee taken.

In Storm vindt u hier de verschillende betrokken onderdelen en hoe deze van invloed zijn op het niveau van parallelle uitvoering dat u hebt:

  • Het hoofdknooppunt (in Storm Nimbus genoemd) wordt gebruikt voor het verzenden en beheren van taken. Deze knooppunten hebben geen invloed op de mate van parallelle uitvoering.
  • De supervisor-knooppunten. In HDInsight komt dit overeen met een azure-VM met een werkknooppunt.
  • De werkroltaken zijn Storm-processen die worden uitgevoerd op de VM's. Elke werkroltaak komt overeen met een JVM-exemplaar. Storm verdeelt het aantal werkprocessen dat u opgeeft zo gelijkmatig mogelijk over de werkknooppunten.
  • Uitvoerexemplaren van spout en bolt. Elk uitvoerexemplaren komt overeen met een thread die wordt uitgevoerd binnen de werkrollen (JVM's).
  • Storm-taken. Dit zijn logische taken die door elk van deze threads worden uitgevoerd. Dit verandert niet het niveau van parallelle uitvoering, dus u moet evalueren of u meerdere taken per uitvoerder nodig hebt of niet.

Haal de beste prestaties van Data Lake Storage Gen1

Wanneer u met Data Lake Storage Gen1 werkt, krijgt u de beste prestaties als u het volgende doet:

  • Voeg uw kleine toevoegsels samen in grotere maten (idealiter 4 MB).
  • Doe zoveel mogelijk gelijktijdige aanvragen. Omdat elke boutdraad leesbewerkingen blokkeert, wilt u ergens in het bereik van 8-12 threads per kern hebben. Hierdoor blijven de NIC en de CPU goed gebruikt. Een grotere VM maakt meer gelijktijdige aanvragen mogelijk.

Voorbeeldtopologie

Stel dat u een cluster met acht werkknooppunten hebt met een Azure-VM D13v2. Deze VM heeft acht kernen, dus van de acht werkknooppunten hebt u in totaal 64 kernen.

Stel dat we acht boutdraden per kern doen. Gezien 64 kernen betekent dit dat we in totaal 512 boltexemplaren (d.w.w. threads) willen hebben. In dit geval beginnen we met één JVM per VM en gebruiken we voornamelijk de thread-gelijktijdigheid binnen de JVM om gelijktijdigheid te bereiken. Dat betekent dat we acht werktaken (één per Azure-VM) en 512 boltexecutors nodig hebben. Gezien deze configuratie probeert Storm de werkrollen gelijkmatig te verdelen over werkknooppunten (ook wel supervisorknooppunten genoemd), waardoor elk werkknooppunt één JVM krijgt. Storm probeert nu binnen de supervisors de uitvoerders gelijkmatig te verdelen over supervisors, waarbij elke supervisor (dat wil gezegd, JVM) acht threads elk krijgt.

Aanvullende parameters afstemmen

Nadat u de basistopologie hebt, kunt u overwegen of u een van de parameters wilt aanpassen:

  • Aantal JVM's per werkknooppunt. Als u een grote gegevensstructuur (bijvoorbeeld een opzoektabel) hebt die u in het geheugen host, vereist elke JVM een afzonderlijke kopie. U kunt ook de gegevensstructuur voor veel threads gebruiken als u minder JVM's hebt. Voor de I/O van de bolt maakt het aantal JVM's niet zoveel verschil als het aantal threads dat over deze JVM's wordt toegevoegd. Voor het gemak is het een goed idee om één JVM per werkrol te hebben. Afhankelijk van wat uw bolt doet of welke toepassingsverwerking u nodig hebt, moet u dit nummer mogelijk wijzigen.
  • Aantal spout-uitvoerders. Omdat in het voorgaande voorbeeld gebruik wordt gemaakt van bouten voor het schrijven naar Data Lake Storage Gen1, is het aantal spouts niet direct relevant voor de prestaties van de bout. Afhankelijk van de hoeveelheid verwerking of I/O die in de spout plaatsvindt, is het echter een goed idee om de spouts af te stemmen voor de beste prestaties. Zorg ervoor dat je voldoende spouts hebt om de bouten bezig te houden. De uitgangssnelheden van de spouts moeten overeenkomen met de doorvoer van de bouten. De werkelijke configuratie is afhankelijk van de spout.
  • Aantal taken. Elke bout loopt als één schroefdraad. Extra taken per bolt bieden geen extra gelijktijdigheid. De enige keer dat ze van nut zijn, is als uw proces van het bevestigen van de tuple een groot deel van de uitvoeringstijd van uw bouten in beslag neemt. Het is een goed idee om veel tuples in een grotere toevoeg te groeperen voordat u een bevestiging van de bout verzendt. In de meeste gevallen bieden meerdere taken dus geen extra voordeel.
  • Lokale groepering of willekeurige groepering. Wanneer deze instelling is ingeschakeld, worden tuples verzonden naar bouten binnen hetzelfde werkproces. Dit vermindert communicatie tussen processen en netwerkoproepen. Dit wordt aanbevolen voor de meeste topologieën.

Dit basisscenario is een goed uitgangspunt. Test met uw eigen gegevens om de voorgaande parameters aan te passen voor optimale prestaties.

De spout afstemmen

U kunt de volgende instellingen wijzigen om de spout af te stemmen.

  • Tuple-time-out: topology.message.timeout.secs. Deze instelling bepaalt de hoeveelheid tijd die nodig is om een bericht te voltooien en bevestiging te ontvangen, voordat het als mislukt wordt beschouwd.

  • Maximaal geheugen per werkproces: worker.childopts. Met deze instelling kunt u aanvullende opdrachtregelparameters voor de Java-werkrollen opgeven. De meest gebruikte instelling hier is XmX, waarmee het maximale geheugen wordt bepaald dat is toegewezen aan de heap van een JVM.

  • Maximale spout in behandeling: topology.max.spout.pending. Deze instelling bepaalt het aantal tuples dat op elk gewenst moment in flight kan worden uitgevoerd (nog niet bevestigd op alle knooppunten in de topologie) per spout-thread.

    Een goede berekening is het schatten van de grootte van elk van uw tuples. Zoek vervolgens uit hoeveel geheugen een spout-thread heeft. Het totale geheugen dat is toegewezen aan een thread, gedeeld door deze waarde, moet u de bovengrens geven voor de parameter max spout in behandeling.

De bout afstemmen

Wanneer u naar Data Lake Storage Gen1 schrijft, stelt u een synchronisatiebeleid voor grootte (buffer aan de clientzijde) in op 4 MB. Een flushing of hsync() wordt vervolgens alleen uitgevoerd wanneer de buffergrootte op deze waarde is. Het Data Lake Storage Gen1-stuurprogramma op de werkrol-VM voert deze buffer automatisch uit, tenzij u expliciet een hsync() uitvoert.

De standaard Data Lake Storage Gen1 Storm Bolt heeft een beleidsparameter voor groottesynchronisatie (fileBufferSize) die kan worden gebruikt om deze parameter af te stemmen.

In I/O-intensieve topologieën is het een goed idee om elke bolt-thread naar een eigen bestand te laten schrijven en een beleid voor bestandsrotatie (fileRotationSize) in te stellen. Wanneer het bestand een bepaalde grootte bereikt, wordt de stroom automatisch leeggemaakt en wordt er een nieuw bestand naar geschreven. De aanbevolen bestandsgrootte voor rotatie is 1 GB.

Tuple-gegevens verwerken

In Storm houdt een spout vast aan een tuple totdat deze expliciet door de bout wordt bevestigd. Als een tuple door de bout is gelezen, maar nog niet is bevestigd, is de uitloop mogelijk niet in Data Lake Storage Gen1 back-end gebleven. Nadat een tuple is bevestigd, kan de spout worden gegarandeerd persistentie door de bout en kan vervolgens de brongegevens worden verwijderd uit de bron die wordt gelezen.

Voor de beste prestaties op Data Lake Storage Gen1 hebt u de boutbuffer 4 MB aan tuplegegevens. Schrijf vervolgens naar de Data Lake Storage Gen1 back-end als een schrijfbewerking van 4 MB. Nadat de gegevens naar het archief zijn geschreven (door hflush()aan te roepen, kan de bolt de gegevens terug naar de spout bevestigen. Dit is wat de hier geleverde voorbeeldbout doet. Het is ook acceptabel om een groter aantal tuples vast te houden voordat de hflush()-aanroep wordt uitgevoerd en de tuples worden bevestigd. Dit verhoogt echter het aantal tuples in flight dat de spout moet bevatten en verhoogt daarom de hoeveelheid geheugen die per JVM nodig is.

Notitie

Toepassingen moeten mogelijk vaker tuples erkennen (met een gegevensgrootte van minder dan 4 MB) om andere niet-prestatieredenen. Dit kan echter van invloed zijn op de I/O-doorvoer naar de back-end van de opslag. Weeg deze afweging zorgvuldig af tegen de I/O-prestaties van de bout.

Als de snelheid van binnenkomende tuples niet hoog is, waardoor het lang duurt voordat de buffer van 4 MB is gevuld, kunt u dit beperken door:

  • Het aantal bouten verminderen, zodat er minder buffers zijn om te vullen.
  • Met een beleid op basis van tijd of aantal, waarbij elke x flushes of elke y milliseconden een hflush() wordt geactiveerd en de tot nu toe verzamelde tuples worden bevestigd.

De doorvoer is in dit geval lager, maar met een traag aantal gebeurtenissen is maximale doorvoer toch niet het grootste doel. Deze oplossingen helpen u de totale tijd te verkorten die nodig is om een tuple door te laten stromen naar de store. Dit kan van belang zijn als u een realtime-pijplijn wilt, zelfs met een lage gebeurtenissnelheid. Houd er ook rekening mee dat als uw binnenkomende tuple-snelheid laag is, u de parameter topology.message.timeout_secs moet aanpassen, zodat er geen time-out optreedt voor de tuples terwijl ze worden gebufferd of verwerkt.

Uw topologie bewaken in Storm

Terwijl uw topologie wordt uitgevoerd, kunt u deze bewaken in de Storm-gebruikersinterface. Dit zijn de belangrijkste parameters om naar te kijken:

  • Totale latentie van procesuitvoering. Dit is de gemiddelde tijd die een tupel nodig heeft om door de tuit te worden uitgezonden, door de bout verwerkt en bevestigd.

  • Totale latentie van bolt-proces. Dit is de gemiddelde tijd die de tuple aan de bout doorbrengt totdat deze een bevestiging ontvangt.

  • Totale latentie van bolt-uitvoering. Dit is de gemiddelde tijd die door de bolt wordt besteed in de execute-methode.

  • Aantal fouten. Dit verwijst naar het aantal tuples dat niet volledig kon worden verwerkt voordat er een time-out optrad.

  • Capaciteit. Dit is een meting van hoe druk uw systeem is. Als dit getal 1 is, werken uw bouten zo snel mogelijk. Als deze kleiner is dan 1, verhoogt u de parallelle uitvoering. Als deze groter is dan 1, vermindert u de parallelle uitvoering.

Veelvoorkomende problemen oplossen

Hier volgen enkele veelvoorkomende scenario's voor probleemoplossing.

  • Veel tuples hebben een time-out. Bekijk elk knooppunt in de topologie om te bepalen waar het knelpunt zich bevindt. De meest voorkomende reden hiervoor is dat de bouten de spouts niet kunnen bijhouden. Dit leidt tot tuples die de interne buffers verstoppen terwijl ze wachten om te worden verwerkt. Overweeg om de time-outwaarde te verhogen of de maximale spout in behandeling te verlagen.

  • Er is een hoge latentie bij totale procesuitvoering, maar een lage bolt-proceslatentie. In dit geval is het mogelijk dat de tuples niet snel genoeg worden bevestigd. Controleer of er voldoende bevestigingsbevestigingen zijn. Een andere mogelijkheid is dat ze te lang in de wachtrij staan voordat de bouten ze gaan verwerken. Verlaag het maximum aantal spouts dat in behandeling is.

  • Er is een hoge latentie bij het uitvoeren van bolts. Dit betekent dat de execute()-methode van uw bout te lang duurt. Optimaliseer de code of bekijk de schrijfgrootten en het gedrag van het leegmaken.

Data Lake Storage Gen1 beperken

Als u de bandbreedtelimieten van Data Lake Storage Gen1 bereikt, ziet u mogelijk taakfouten. Controleer taaklogboeken op beperkingsfouten. U kunt de parallelle uitvoering verminderen door de containergrootte te vergroten.

Als u wilt controleren of u wordt beperkt, schakelt u de logboekregistratie voor foutopsporing aan de clientzijde in:

  1. Wijzig in Ambari>Storm>Config>Advanced storm-worker-log4j<root level="info"> in <root level="debug">. Start alle knooppunten/service opnieuw om de configuratie van kracht te laten worden.
  2. Bewaak de Storm-topologielogboeken op werkknooppunten (onder /var/log/storm/worker-artifacts/<TopologyName>/<port>/worker.log) voor Data Lake Storage Gen1 beperkings-uitzonderingen.

Volgende stappen

In dit blog vindt u meer informatie over het afstemmen van de prestaties voor Storm.

Zie dit voorbeeld op GitHub voor een extra voorbeeld om uit te voeren.