Při běhu na EC2 často nemůžete vyhrát, pokud jde o typy instancí. Jedním z cenově výhodnějších dostupných typů je c1.xlarge. Má dostatek CPU, aby zvládl zhutnění, slušné množství disku a vysoké síťové I/O. Zjistili jsme však, že relativně nízká paměť 7 GB na c1.xlarge často vede k problémům se stabilitou ve vysoce souběžných clusterech HBase. I když existují další dražší možnosti, tento výukový program HBase vám pomůže co nejlépe využít vaše c1.xlarge RegionServers.
1. Snižte počet regionů na RegionServer
V ideálním případě byste měli mít méně než 100 regionů na RegionServer . Paměťové úložiště je rozděleno pro použití všemi aktivními oblastmi a každá oblast přidává (ve výchozím nastavení) 2 MB paměti pro MSLAB. Snížení tohoto čísla pomůže, aby věci běžely hladce, a to nejen z hlediska paměti.
2. Ukrást paměť z jiných služeb
Na těchto typech instancí byste rozhodně neměli spouštět TaskTracker se svým RegionServerem, ale s největší pravděpodobností používáte místní DataNode. Typická konfigurace vyžaduje 1 GB paměti pro DataNode, ale zjistili jsme, že v mnoha případech toho tolik nepotřebujete. Před zavedením této funkce ověřte své metriky, ale byli jsme naprosto v bezpečí zkrátili jsme hromadu DataNode na 400 MB . Tento pěkný 624MB kus pomůže HBase dostat se o něco dále.
3. Vylaďte nebo deaktivujte MSLAB
Pokud po krádeži paměti a ořezání oblastí stále máte problémy, můžete jít o krok dále. Jak jsem zmínil, funkce MSLAB standardně přidává 2 MB režie haldy pro každou oblast. Tuto vyrovnávací paměť můžete snížit s hbase.hregion.memstore.mslab.chunksize . Čím níže jdete, tím je to méně efektivní, ale také méně paměti. Úplně jej deaktivujte pomocí hbase.hregion.memstore.mslab.enabled .
4. Buďte agresivní ohledně ukládání do mezipaměti a dávkování
Ukládání do mezipaměti (Scan#setCaching(int) ) a dávkování (Scan#setBatch(int) ) jsou skvělé pro omezení vlivu latence sítě na velká skenování. Bohužel také vyžadují více paměti na straně klienta i serveru. Mějte na paměti kompromis v rychlosti, ale užijte si trochu více stability tím, že je vyladíte , podle potřeby co nejblíže hodnotě 1.
RegionServer musí mít také dostatek paměti, aby zvládl všechny vaše souběžné zápisy. Pokud intenzivně dávkujete své zápisy nebo posíláte několik velmi velkých hodnot buněk, pravděpodobně narazíte na OutOfMemoryExceptions. Zde také snižte dávkování nebo jinak najděte způsob, jak zmenšit velikost hodnot buněk.
5. Ovládejte zatížení z Hadoopu
Pokud spouštíte úlohy hadoop proti vašim datům HBase, v podstatě spouštíte spoustu velkých skenů. V úloze HBase MapReduce se každý region stává mapovačem. Pokud máte více než 1 region na RegionServer, je pravděpodobné, že v určitém okamžiku bude několik mapovačů skenovat stejný RegionServer současně. Každé z těchto skenů zabírá paměť, disk a zdroje CPU a při vícenásobném sestavení může způsobit určitou bolest.
Snížení hbase.regionserver.handler.count pomůže omezit počet aktivních připojení zabírajících paměť, ale stále můžete mít problém, pokud všechny obslužné programy zpracovávají rozsáhlé skenování celé oblasti. Pomocí našeho rozšíření TableInputFormat můžete snadno ovládat, kolik souběžných mapovačů běží proti jednomu RegionServeru , což poskytuje předvídatelnější využití paměti.
Pokud zapisujete do HBase z redukce, budete chtít rozdělování ovládat i tam. To lze snadno implementovat pomocí Partitioner společnosti Hadoop rozhraní pomocí HBaseAdmin HBase rozhraní poskytující region mapování RegionServer.
Spuštění HBase při nedostatku paměti je obtížné, ale ne nemožné
S těmito tipy v ruce byste měli být na dobré cestě k přežití operací v prostředí s nízkou pamětí. V době extrémně levné a rychlé RAM může být frustrující bojovat o každý megabajt paměti. Ale postupujte podle těchto tipů a váš finanční ředitel vám poděkuje, že jste tento cenově efektivní typ instance maximálně využili. Pro ty, kteří mají trochu větší finanční svobodu, prozkoumáme dopad nových typů instancí I2 společnosti Amazon v příštím příspěvku . Takže zůstaňte naladěni!
Tento článek se původně objevil na dev.hubspot.com