sql >> Databasteknik >  >> NoSQL >> HBase

HBase:5 tips för att köra på EC2 med lågt minne

När du kör på EC2 kan du ofta inte vinna när det kommer till instanstyper. En av de mer kostnadseffektiva typerna som finns är c1.xlarge. Den har tillräckligt med CPU för att hantera komprimering, en anständig mängd disk och hög nätverks-I/O. Vi har dock upptäckt att det relativt låga minnet på 7 GB på c1.xlarge ofta leder till stabilitetsproblem i mycket samtidiga HBase-kluster. Även om det finns andra dyrare alternativ, hjälper den här HBase-handledningen dig att få ut det mesta av dina c1.xlarge RegionServers.

1. Minska antalet regioner per RegionServer

Helst bör du ha mindre än 100 regioner per RegionServer . Memstore är uppdelat för användning av alla aktiva regioner, och varje region lägger till (som standard) 2 MB minne för MSLAB. Att skära ner det här antalet hjälper saker att fungera smidigt, och inte bara ur minnessynpunkt.

2. Stjäl minne från andra tjänster

Du borde definitivt inte köra en TaskTracker med din RegionServer på dessa instanstyper, men du kör med största sannolikhet en lokal DataNode. En typisk konfiguration kräver 1 GB minne för en DataNode, men vi har upptäckt att du inte behöver så mycket i många fall. Verifiera dina mätvärden innan du lanserar detta, men vi var helt säkra att skära ned DataNode-högen till 400 MB . Denna fina bit på 624 MB hjälper HBase att komma lite längre.

3. Ställ in eller inaktivera MSLAB

Om du fortfarande har problem efter att ha stulit minne och skär ner regioner kan du gå ett steg längre. Som jag nämnde lägger MSLAB-funktionen till 2 MB heap overhead som standard för varje region. Du kan justera den här bufferten med hbase.hregion.memstore.mslab.chunksize . Ju lägre du går desto mindre effektivt är det, men desto mindre minneskostnader också. Inaktivera det helt och hållet med hbase.hregion.memstore.mslab.enabled .

4. Var aggressiv när det gäller cachning och batchning

Cachning (Scan#setCaching(int) ) och batchning (Scan#setBatch(int) ) är bra för att begränsa effekten av nätverkslatens på stora skanningar. Tyvärr kräver de också mer minne på både klient- och serversidan. Tänk på hastighetsavvägningen, men njut av lite mer stabilitet genom att sänka dessa , så nära värdet 1 som behövs.

RegionServer måste också ha tillräckligt med minne för att hantera alla dina samtidiga skrivningar. Om du satsar mycket på dina skrivningar, eller skickar några mycket stora cellvärden, kommer du sannolikt att stöta på OutOfMemoryExceptions. Sänk mängden mängd här också, eller på annat sätt hitta ett sätt att krympa storleken på dina cellvärden.

5. Styr belastningen från Hadoop

Om du kör hadoop-jobb mot dina HBase-data kör du i princip många stora skanningar. I ett HBase MapReduce-jobb blir varje region en kartläggare. Om du har mer än 1 region per RegionServer, är chansen stor att du kommer att ha några mappare som skannar samma RegionServer samtidigt någon gång. Var och en av dessa skanningar tar minnes-, disk- och CPU-resurser och när flera skanningar byggs upp kan det orsaka en del smärta.

Sänker hbase.regionserver.handler.count kommer att hjälpa till att begränsa antalet aktiva anslutningar som tar minne, men du kan fortfarande ha problem om alla hanterare hanterar stora genomsökningar av hela regionen. Med vårt tillägg av TableInputFormat kan du enkelt kontrollera hur många samtidiga mappare som körs mot en enda RegionServer , vilket ger mer förutsägbar minnesanvändning.

Om du skriver till HBase från en reducerare kommer du att vilja styra partitioneringen där också. Detta implementeras enkelt med Hadoops Partitioner gränssnitt, med HBases HBaseAdmin gränssnitt som tillhandahåller regionen till RegionServer-mappningar.

Att köra HBase på lågt minne är svårt, men inte omöjligt

Med dessa tips i hand bör du vara på god väg att överleva operationer i din miljö med lågt minne. Det kan vara frustrerande att slåss om varje megabyte minne i en tid med extremt billigt, snabbt RAM-minne. Men följ dessa tips och din CFO kommer att tacka dig för att du får ut det mesta av denna kostnadseffektiva instanstyp. För de med lite mer ekonomisk frihet, kommer vi att utforska effekten av Amazons nya I2-instanstyper i ett framtida inlägg . Så håll utkik!

Den här artikeln publicerades ursprungligen på dev.hubspot.com


  1. MongoDB-skärvor och obalanserade aggregationsbelastningar

  2. Ansluter MongoDB till Ruby med självsignerade certifikat för SSL

  3. Spring boot + Redis - Genererar en konstig nyckel

  4. Aggregerande i lokal tidszon i mongodb