Når du kører på EC2, kan du ofte ikke vinde, når det kommer til instanstyper. En af de mere omkostningseffektive typer, der findes, er c1.xlarge. Den har nok CPU til at håndtere komprimeringer, en anstændig mængde disk og høj netværks-I/O. Vi har dog fundet ud af, at den relativt lave hukommelse på 7 GB på c1.xlarge ofte fører til stabilitetsproblemer i meget samtidige HBase-klynger. Selvom der er andre dyrere muligheder, vil denne HBase-vejledning hjælpe dig med at få mest muligt ud af dine c1.xlarge RegionServers.
1. Reducer antallet af regioner pr. RegionServer
Ideelt set bør du have mindre end 100 regioner pr. RegionServer . Memstore er opdelt til brug af alle aktive regioner, og hver region tilføjer (som standard) 2 MB hukommelse til MSLAB. At skære dette tal ned vil hjælpe tingene til at køre glat, og ikke kun fra et hukommelsessynspunkt.
2. Stjæl hukommelse fra andre tjenester
Du burde bestemt ikke køre en TaskTracker med din RegionServer på disse instanstyper, men du kører højst sandsynligt en lokal DataNode. En typisk konfiguration kræver 1 GB hukommelse til en DataNode, men vi har fundet ud af, at du ikke har brug for så meget i mange tilfælde. Bekræft dine metrics, før du ruller dette ud, men vi var helt sikre ved at skære DataNode-bunken ned til 400 MB . Denne flotte 624MB-klump vil hjælpe HBase med at komme lidt længere.
3. Indstil eller deaktiver MSLAB
Hvis du stadig har problemer efter at have stjålet hukommelse og skåret ned i områder, kan du gå et skridt videre. Som jeg nævnte, tilføjer MSLAB-funktionen 2 MB heap-overhead som standard for hver region. Du kan justere denne buffer ned med hbase.hregion.memstore.mslab.chunksize . Jo lavere du går, jo mindre effektiv er den, men jo mindre hukommelsesomkostninger også. Deaktiver det helt med hbase.hregion.memstore.mslab.enabled .
4. Vær aggressiv omkring caching og batching
Caching (Scan#setCaching(int) ) og batching (Scan#setBatch(int) ) er gode til at begrænse effekten af netværksforsinkelse på store scanninger. Desværre kræver de også mere hukommelse på både klient- og serversiden. Husk hastighedsafvejningen, men nyd lidt mere stabilitet ved at tune disse ned , så tæt på en værdi på 1 som nødvendigt.
RegionServeren skal også have nok hukommelse til at håndtere alle dine samtidige skrivninger. Hvis du samler dine skrivninger kraftigt eller sender nogle få meget store celleværdier, vil du sandsynligvis løbe ind i OutOfMemoryExceptions. Sænk din batching også her, eller find på anden måde en måde at formindske størrelsen af dine celleværdier på.
5. Styr belastning fra Hadoop
Hvis du kører hadoop-job mod dine HBase-data, kører du som udgangspunkt en masse store scanninger. I et HBase MapReduce-job bliver hver region en kortlægger. Hvis du har mere end 1 region pr. RegionServer, er der stor sandsynlighed for, at du på et tidspunkt vil have et par kortere, der scanner den samme RegionServer samtidigt. Hver af disse scanninger tager hukommelse, disk og CPU-ressourcer, og når flere opbygges, kan det forårsage en vis smerte.
Sænker hbase.regionserver.handler.count vil hjælpe med at begrænse antallet af aktive forbindelser, der tager hukommelse, men du kan stadig have et problem, hvis alle behandlere håndterer store scanninger i hele regionen. Ved at bruge vores udvidelse af TableInputFormat kan du let styre, hvor mange samtidige kortlæggere, der kører mod en enkelt RegionServer , hvilket giver mere forudsigelig hukommelsesbrug.
Hvis du skriver til HBase fra en reducering, vil du også gerne styre partitioneringen der. Dette implementeres nemt ved hjælp af Hadoops Partitioner interface med HBases HBaseAdmin grænseflade, der leverer regionen til RegionServer-kortlægninger.
At køre HBase på lav hukommelse er svært, men ikke umuligt
Med disse tips i hånden burde du være godt på vej til at overleve operationer i dit miljø med lav hukommelse. Det kan være frustrerende at kæmpe for hver megabyte hukommelse i en tid med ekstremt billig, hurtig RAM. Men følg disse tips, og din CFO vil takke dig for at få mest muligt ud af denne omkostningseffektive instanstype. For dem med lidt mere økonomisk frihed, vil vi undersøge virkningen af Amazons nye I2-instanstyper i et fremtidigt indlæg . Så følg med!
Denne artikel blev oprindeligt vist på dev.hubspot.com