Apache HBase + Apache Hadoop + Xceivers

Inleiding

Sommige configuratie-eigenschappen in Apache Hadoop hebben een direct effect op clients, zoals Apache HBase. Een van die eigenschappen heet 'dfs.datanode.max.xcievers' en hoort bij het HDFS-subproject. Het definieert het aantal server-side threads en - tot op zekere hoogte - sockets die worden gebruikt voor gegevensverbindingen. Als u dit aantal te laag instelt, kan dit problemen veroorzaken als u groeit of het gebruik van uw cluster verhoogt. Dit bericht helpt je te begrijpen wat er tussen de client en de server gebeurt en hoe je een redelijk aantal voor deze eigenschap kunt bepalen.

Het probleem

Aangezien HBase alles opslaat wat het nodig heeft in HDFS, kan de harde bovengrens die wordt opgelegd door de configuratie-eigenschap "dfs.datanode.max.xcievers" ertoe leiden dat er te weinig bronnen beschikbaar zijn voor HBase, wat zich manifesteert als IOExceptions aan beide zijden van de verbinding. Hier is een voorbeeld van de HBase-mailinglijst [1], waar de volgende berichten aanvankelijk aan de RegionServer-kant werden vastgelegd:

2008-11-11 19:55:52,451 INFO org.apache.hadoop.dfs.DFSClient: Uitzondering in createBlockOutputStream java.io.IOException:Kan niet lezen uit stream
2008-11-11 19:55:52,451 INFO org.apache.hadoop.dfs.DFSClient:Blokkering verlaten blk_-5467014108758633036_595771
2008-11- 11 19:55:58,455 WARN org.apache.hadoop.dfs.DFSClient:DataStreamer-uitzondering:java.io.IOException:kan geen nieuw blok maken.
2008-11-11 19:55:58,455 WARN org.apache .hadoop.dfs.DFSClient:Foutherstel voor blok blk_-5467014108758633036_595771 slechte datanode[0]
2008-11-11 19:55:58,482 FATAL org.apache.hadoop.hbase.regionserver.Flusher:Opnieuw afspelen van hlog vereist . Afsluiten van de server forceren

Door dit te correleren met de Hadoop DataNode-logboeken bleek het volgende item:

FOUT org.apache.hadoop.dfs.DataNode: DatanodeRegistration(10.10.10.53:50010,storageID=DS-1570581820-10.10.10.53-50010-1224117842339,infoPort=50075, ipcPort=50020):DataXceiver:java.io.IOException: xceiverCount 258 overschrijdt de limiet van gelijktijdige xcievers 256

In dit voorbeeld zorgde de lage waarde van "dfs.datanode.max.xcievers" voor de DataNodes ervoor dat de hele RegionServer werd afgesloten. Dit is echt een slechte situatie. Helaas is er geen vaste regel die uitlegt hoe de vereiste limiet moet worden berekend. Het wordt vaak aangeraden om het aantal te verhogen van de standaardwaarde van 256 naar iets als 4096 (zie [1], [2], [3], [4] en [5] ter referentie). Dit wordt gedaan door deze eigenschap toe te voegen aan het bestand hdfs-site.xml van alle DataNodes (merk op dat het verkeerd is gespeld):

    dfs.datanode.max.xcievers
4096

Opmerking:u moet uw DataNodes opnieuw opstarten nadat u deze wijziging in het configuratiebestand heeft aangebracht.

Dit zou moeten helpen bij het bovenstaande probleem, maar misschien wilt u toch meer weten over hoe dit allemaal samenwerkt en wat HBase met deze bronnen doet. We zullen dit in de rest van dit bericht bespreken. Maar voordat we dat doen, moeten we duidelijk zijn waarom je dit aantal niet gewoon heel hoog kunt instellen, zeg 64K en klaar ermee.

Er is een reden voor een bovengrens, en die is tweeledig:ten eerste hebben threads hun eigen stapel nodig, wat betekent dat ze geheugen in beslag nemen. Voor huidige servers betekent dit standaard 1 MB per thread[6]. Met andere woorden, als u alle 4096 DataXceiver-threads opgebruikt, heeft u ongeveer 4 GB aan opslagruimte nodig om ze op te vangen. Dit snijdt in de ruimte die u hebt toegewezen voor memstores en blokcaches, evenals alle andere bewegende delen van de JVM. In het ergste geval kunt u een OutOfMemoryException tegenkomen en is het RegionServer-proces toast. U wilt deze eigenschap op een redelijk hoog aantal instellen, maar ook niet te hoog.

Ten tweede, als je deze vele threads actief hebt, zul je ook zien dat je CPU steeds meer wordt belast. Er zullen veel contextwisselingen plaatsvinden om al het gelijktijdige werk af te handelen, wat middelen kost voor het echte werk. Net als bij de zorgen over het geheugen, wil je dat het aantal threads niet grenzeloos groeit, maar een redelijke bovengrens biedt - en dat is waar "dfs.datanode.max.xcievers" voor is.

Hadoop-bestandssysteemdetails

Vanaf de clientzijde biedt de HDFS-bibliotheek de abstractie genaamd Path. Deze klasse vertegenwoordigt een bestand in een bestandssysteem dat wordt ondersteund door Hadoop, vertegenwoordigd door de klasse FileSystem. Er zijn een paar concrete implementaties van de abstracte FileSystem-klasse, waaronder het DistributedFileSytem, ​​dat HDFS vertegenwoordigt. Deze klasse omhult op zijn beurt de eigenlijke DFSClient-klasse die alle interacties met de externe servers afhandelt, d.w.z. de NameNode en de vele DataNodes.

Wanneer een client, zoals HBase, een bestand opent, doet hij dit bijvoorbeeld door de methoden open() of create() van de klasse FileSystem aan te roepen, hier de meest simplistische incarnaties

  public DFSInputStream open(String src) genereert IOException
public FSDataOutputStream create(Path f) genereert IOException

De geretourneerde stream-instantie heeft een socket en thread aan de serverzijde nodig, die worden gebruikt om gegevensblokken te lezen en te schrijven. Ze maken deel uit van het contract om gegevens uit te wisselen tussen de client en de server. Merk op dat er andere, op RPC gebaseerde protocollen in gebruik zijn tussen de verschillende machines, maar voor het doel van deze discussie kunnen ze worden genegeerd.

De geretourneerde stream-instantie is een gespecialiseerde DFSOutputStream- of DFSInputStream-klasse, die alle interactie met de NameNode afhandelt om erachter te komen waar de kopieën van de blokken zich bevinden, en de datacommunicatie per blok per DataNode.

Aan de serverkant verpakt de DataNode een instantie van DataXceiverServer, de eigenlijke klasse die de bovenstaande configuratiesleutel leest en ook de bovenstaande uitzondering genereert wanneer de limiet wordt overschreden.

Wanneer de DataNode start, wordt een threadgroep gemaakt en wordt de genoemde DataXceiverServer-instantie als volgt gestart:

  this.threadGroup =new ThreadGroup(“dataXceiverServer”);
this.dataXceiverServer =new Daemon( threadGroup,
nieuwe DataXceiverServer(ss, conf, dit));
this.threadGroup.setDaemon(true); // automatisch vernietigen wanneer leeg

Houd er rekening mee dat de DataXceiverServer-thread al één plek in de threadgroep inneemt. De DataNode heeft ook deze interne klasse om het aantal momenteel actieve threads in deze groep op te halen:

  /** Aantal gelijktijdige xceivers per node. */
int getXceiverCount() {
return threadGroup ==null ? 0:threadGroup.activeCount();
}

Lees- en schrijfblokkades, zoals geïnitieerd door de client, zorgen ervoor dat er een verbinding tot stand wordt gebracht, die door de DataXceiverServer-thread wordt verpakt in een DataXceiver-instantie. Tijdens deze overdracht wordt een thread gemaakt en geregistreerd in de bovenstaande threadgroep. Dus voor elke actieve lees- en schrijfbewerking wordt een nieuwe thread aan de serverzijde bijgehouden. Als het aantal threads in de groep het geconfigureerde maximum overschrijdt, wordt de genoemde uitzondering gegenereerd en vastgelegd in de logboeken van de DataNode:

  if (curXceiverCount> dataXceiverServer.maxXceiverCount) {
throw new IOException(“xceiverCount ” + curXceiverCount
+ ” overschrijdt de limiet van gelijktijdige xcievers ”
+ dataXceiverServer.maxXceiverCount);
}

Implicaties voor klanten

Nu is de vraag, hoe verhoudt het lezen en schrijven van de client zich tot de server-side threads. Voordat we echter ingaan op de details, laten we de foutopsporingsinformatie gebruiken die de DataXceiver-klasse logt wanneer deze wordt gemaakt en gesloten

  LOG.debug(“Aantal actieve verbindingen is:” + datanode.getXceiverCount());
…
LOG.debug(datanode.dnRegistration + “:Aantal actieve verbindingen is:”     + datanode.getXceiverCount());

en controleer tijdens het opstarten van HBase wat er op de DataNode is vastgelegd. Omwille van de eenvoud wordt dit gedaan op een pseudo-gedistribueerde installatie met een enkele DataNode- en RegionServer-instantie. Het volgende toont de bovenkant van de statuspagina van de RegionServer.

Het belangrijkste deel bevindt zich in het gedeelte "Metrieken", waar "storefiles =22" staat. Dus, ervan uitgaande dat HBase op zijn minst zoveel bestanden heeft om te verwerken, plus enkele extra bestanden voor het write-ahead-logboek, zouden we het bovenstaande logs-bericht moeten zien dat we ten minste 22 "actieve verbindingen" hebben. Laten we HBase starten en de logbestanden van DataNode en RegionServer controleren:

Opdrachtregel:

$ bin/start-hbase.sh
…

DataNode-logboek:

2012-03-05 13:01:35,309 DEBUG org.apache.hadoop.hdfs.server.datanode. DataNode:Aantal actieve verbindingen is:1
2012-03-05 13:01:35,315 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:DatanodeRegistration (127.0.0.1:50010, storageID=DS- 1423642448-10.0.0.64-50010-1321352233772, infoPort=50075, ipcPort=50020):Aantal actieve verbindingen is:2
12/03/05 13:01:35 INFO regionserver.MemStoreFlusher:globalMemStoreLimit=396.7m, globalMemStoreLimitLowMark=347.1m, maxHeap=991.7m
03/12/05 13:01:39 INFO http.HttpServer:Poort geretourneerd door webServer.getConnectors()[0].getLocalPort() voor open() is -1 . De listener openen op 60030
2012-03-05 13:01:40,003 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:Aantal actieve verbindingen is:1
12/03/05 13:01:40 INFO regionserver.HRegionServer:Verzoek ontvangen om regio te openen:-ROOT-,,0.70236052
2012-03-05 13:01:40,882 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode :Aantal actieve verbindingen is:3
2012-03-05 13:01:40,884 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:DatanodeRegistration (127.0.0.1:50010, storageID=DS-1423642448 -10.0.0.64-50010-1321352233772, infoPort=50075, ipcPort=50020):Aantal actieve verbindingen is:4
2012-03-05 13:01:40,888 DEBUG org.apache.hadoop.hdfs.server. datanode.DataNode:Aantal actieve verbindingen is:3
…
12/03/05 13:01:40 INFO regionserver.HRegion:Onlined -ROOT-,,0.70236052; volgende sequenceid=63083
2012-03-05 13:01:40,982 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:Aantal actieve verbindingen is:3
2012-03-05 13 :01:40,983 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:DatanodeRegistration (127.0.0.1:50010, storageID=DS-1423642448-10.0.0.64-50010-1321352233772, infoPort=50075, ipcPort=50020):Aantal actieve verbindingen is:4
…
12/03/05 13:01:41 INFO regionserver.HRegionServer:Verzoek ontvangen om regio te openen:.META.,,1.1028785192
2012-03 -05 13:01:41,026 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:Aantal actieve verbindingen is:3
2012-03-05 13:01:41.027 DEBUG org.apache.hadoop. hdfs.server.datanode.DataNode:DatanodeRegistration (127.0.0.1:50010, storageID=DS-1423642448-10.0.0.64-50010-1321352233772, infoPort=50075, ipcPort=50020):Aantal actieve verbindingen is:4
…
03/12/05 13:01:41 INFO regionserver.HRegion:Onlined .META.,,1.1028785192; next sequenceid=63082
2012-03-05 13:01:41,109 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:Aantal actieve verbindingen is:3
2012-03-05 13 :01:41,114 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:Aantal actieve verbindingen is:4
2012-03-05 13:01:41,117 DEBUG org.apache.hadoop.hdfs.server .datanode.DataNode:Aantal actieve verbindingen is:5
12/03/05 13:01:41 INFO regionserver.HRegionServer:Verzoek ontvangen om 16 regio('s) te openen
12/03/05 13 :01:41 INFO regionserver.HRegionServer:Ontvangen verzoek om regio te openen:usertable,,1330944810191.62a312d67981c86c42b6bc02e6ec7e3f.
12/03/05 13:01:41 INFO regionserver.HRegionServer:Ontvangen verzoek om regio te openen:usertable,,user11203 1330944810191.90d287473fe223f0ddc137020efda25d.
…

2012-03-05 13:01:41,246 DEBUG org.apache.hadoop.hdfs.server.datanode. DataNode:Aantal actieve verbindingen is:6
2012-03-05 13:01:41,248 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:Aantal actieve verbindingen is:7
…
2012-03-05 13:01:41.257 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:DatanodeRegistration (127.0.0.1:50010, storageID=DS-1423642448-10.0.0.64-50010-1321352233772 , infoPort=50075, ipcPort=50020):Aantal actieve verbindingen is:10
2012-03-05 13:01:41.257 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:DatanodeRegistration (127.0. 0.1:50010, storageID=DS-1423642448-10.0.0.64-50010-1321352233772, infoPort=50075, ipcPort=50020):Aantal actieve verbindingen is:9
…
12/03/05 13:01:41 INFO regionserver.HRegion:Onlined gebruikerstabel,gebruiker1120311784,1330944810191.90d287473fe223f0ddc137020efda25d.; volgende sequenceid=62917
12/03/05 13:01:41 INFO regionserver.HRegion:Onlined gebruikerstabel,,1330944810191.62a312d67981c86c42b6bc02e6ec7e3f.; volgende sequenceid=62916
…
12/03/05 13:01:41 INFO regionserver.HRegion:Onlined usertable,user1361265841,1330944811370.80663fcf291e3ce00080599964f406ba.; next sequenceid=62919
2012-03-05 13:01:41,474 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:Aantal actieve verbindingen is:6
2012-03-05 13 :01:41,491 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:Aantal actieve verbindingen is:7
2012-03-05 13:01:41,495 DEBUG org.apache.hadoop.hdfs.server .datanode.DataNode:DatanodeRegistration (127.0.0.1:50010, storageID=DS-1423642448-10.0.0.64-50010-1321352233772, infoPort=50075, ipcPort=50020):Aantal actieve verbindingen is:8
2012-03 -05 13:01:41,508 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:Aantal actieve verbindingen is:7
…
12/03/05 13:01:41 INFO regionserver .HRregio:Onlined gebruikerstabel,gebruiker1964968041,1330944848231.dd89596e9129e1caa7e07f8a491c9734.; next sequenceid=62920
2012-03-05 13:01:41,618 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:Aantal actieve verbindingen is:6
2012-03-05 13 :01:41,621 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:DatanodeRegistration (127.0.0.1:50010, storageID=DS-1423642448-10.0.0.64-50010-1321352233772, infoPort=50075, ipcPort=50020):Aantal actieve verbindingen is:7
…
2012-03-05 13:01:41,829 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:DatanodeRegistration (127.0.0.1:50010, storageID =DS-1423642448-10.0.0.64-50010-1321352233772, infoPort=50075, ipcPort=50020):Aantal actieve verbindingen is:7
12/03/05 13:01:41 INFO regionserver.HRegion:Onlined gebruikerstabel ,gebruiker515290649,1330944849739.d23924dc9e9d5891f332c337977af83d.; next sequenceid=62926
2012-03-05 13:01:41,832 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:Aantal actieve verbindingen is:6
2012-03-05 13 :01:41.838 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:DatanodeRegistration (127.0.0.1:50010, storageID=DS-1423642448-10.0.0.64-50010-1321352233772, infoPort=50075, ipcPort=50020):Aantal actieve verbindingen is:7
12/03/05 13:01:41 INFO regionserver.HRegion:Onlined usertable,user757669512,1330944850808.cd0d6f16d8ae9cf0c9277f5d6c6c6b9f.; next sequenceid=62929
…
2012-03-05 14:01:39,711 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:Aantal actieve verbindingen is:4
2012 -03-05 22:48:41.945 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:DatanodeRegistration (127.0.0.1:50010, storageID=DS-1423642448-10.0.0.64-50010-1321352233772, infoPort=50075, ipcPort=50020):Aantal actieve verbindingen is:4
12/03/05 22:48:41 INFO regionserver.HRegion:Onlined usertable,user757669512,1330944850808.cd0d6f16d8ae9cf0c9277f5d6c6c6b9f.; volgende sequenceid=62929
2012-03-05 22:48:41,963 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:DatanodeRegistration (127.0.0.1:50010, storageID=DS-1423642448-10.0.0.64 -50010-1321352233772, infoPort=50075, ipcPort=50020):Aantal actieve verbindingen is:4

Je kunt zien hoe de regio's de een na de ander worden geopend, maar wat je misschien ook opvalt, is dat het aantal actieve verbindingen nooit oploopt tot 22 - het bereikt amper 10. Waarom is dat? Om dit beter te begrijpen, moeten we zien hoe bestanden in HDFS worden toegewezen aan de server-side DataXceiver-instantie - en de daadwerkelijke threads die ze vertegenwoordigen.

Hadoop diepe duik

De eerder genoemde DFSInputStream en DFSOutputStream zijn echt façades rond de gebruikelijke streamconcepten. Ze verpakken de client-servercommunicatie in deze standaard Java-interfaces, terwijl ze het verkeer intern naar een geselecteerde DataNode routeren - die een kopie van het huidige blok bevat. Het heeft de vrijheid om deze verbinding naar behoefte te openen en te sluiten. Terwijl een client een bestand in HDFS leest, schakelen de klassen van de clientbibliotheek transparant van blok naar blok, en dus van DataNode naar DataNode, dus het moet verbindingen openen en sluiten als dat nodig is.

De DFSInputStream heeft een instantie van een DFSClient.BlockReader-klasse, die de verbinding met de DataNode opent. De stream-instantie roept blockSeekTo() aan voor elke aanroep naar read() die zorgt voor het openen van de verbinding, als die er al is. Zodra een blok volledig is gelezen, wordt de verbinding gesloten. Het sluiten van de stream heeft natuurlijk hetzelfde effect.

De DFSOutputStream heeft een vergelijkbare helperklasse, de DataStreamer. Het volgt de verbinding met de server, die wordt geïnitieerd door de methode nextBlockOutputStream(). Het heeft nog meer interne klassen die helpen bij het wegschrijven van de blokgegevens, die we hier kortheidshalve weglaten.

Zowel schrijf- als leesblokken hebben een thread nodig om de socket en tussenliggende gegevens aan de serverzijde vast te houden, verpakt in de DataXceiver-instantie. Afhankelijk van wat uw klant doet, ziet u dat het aantal verbindingen schommelt rond het aantal momenteel geopende bestanden in HDFS.

Terug naar het HBase-raadsel hierboven:de reden dat je tijdens de start geen 22 (en meer) verbindingen ziet, is dat terwijl de regio's open zijn, de enige vereiste gegevens het infoblok van de HFile zijn. Dit blok wordt gelezen om essentiële details over elk bestand te krijgen, maar wordt dan weer gesloten. Dit betekent dat de server-side resource snel achter elkaar wordt vrijgegeven. De overige vier verbindingen zijn moeilijker te bepalen. U kunt JStack gebruiken om alle threads op de DataNode te dumpen, die in dit voorbeeld dit item toont:

"DataXceiver voor client /127.0.0.1:64281 [verzendblok blk_55327412334432227208_4201]" daemon prio=5 tid=7fb96481d000 nid=0x1178b4000 uitvoerbaar [1178b3000]
java.lang.Thread.State:RUNNABLE
…

"DataXceiver voor client /127.0.0.1:64172 [receiving block blk_-2005512129579433420_4199 client=DFSClient_hb_rs_10.0.0.29 ,60020,1330984111693_1330984118810]” daemon prio=5 tid=7fb966109000 nid=0x1169cb000 uitvoerbaar [1169ca000]
java.lang.Thread.State:RUNNABLE
…

Dit zijn de enige DataXceiver-vermeldingen (in dit voorbeeld), dus het aantal in de threadgroep is een beetje misleidend. Bedenk dat de DataXceiverServer daemon-thread al verantwoordelijk is voor één extra item, wat in combinatie met de twee bovenstaande de drie actieve verbindingen oplevert – wat in feite drie actieve threads betekent. De reden dat het logboek in plaats daarvan vier vermeldt, is dat het de telling registreert van een actieve thread die op het punt staat te eindigen. Dus kort nadat het aantal van vier is geregistreerd, is het er eigenlijk één minder, d.w.z. drie en komt dus overeen met ons aantal actieve threads.

Merk ook op dat de interne hulpklassen, zoals de PacketResponder, een andere thread in de groep bezetten terwijl ze actief zijn. De JStack-uitvoer geeft dat feit aan, en vermeldt de thread als zodanig:

 'PacketResponder 0 for Block blk_-2005512129579433420_4199' daemon prio=5 tid=7fb96384d000 nid=0x116ace000 in Object.wait () [116acd000]
java.lang.Thread.State:TIMED_WAITING (op objectmonitor)
op java.lang.Object.wait(Native Method)
op org.apache.hadoop. hdfs.server.datanode.BlockReceiver$PacketResponder \
.lastDataNodeRun(BlockReceiver.java:779)
– vergrendeld (een org.apache.hadoop.hdfs.server.datanode.BlockReceiver$PacketResponder)
op org.apache.hadoop.hdfs.server.datanode.BlockReceiver$PacketResponder.run(BlockReceiver.java:870)
op java.lang.Thread.run(Thread.java:680)

Deze thread bevindt zich momenteel in de status TIMED_WAITING en wordt niet als actief beschouwd. Dat is de reden waarom de telling die wordt uitgezonden door de DataXceiver-loginstructies, dit soort threads niet omvat. Als ze actief worden doordat de client verzendgegevens verstuurt, gaat het aantal actieve threads weer omhoog. Een ander ding om op te merken is dat deze thread geen aparte verbinding of socket nodig heeft tussen de client en de server. De PacketResponder is slechts een thread aan de serverzijde om blokgegevens te ontvangen en deze naar de volgende DataNode in de schrijfpijplijn te streamen.

Het Hadoop fsck-commando heeft ook een optie om te rapporteren welke bestanden momenteel open staan ​​om te schrijven:

$ hadoop fsck /hbase -openforwrite
FSCK gestart door larsgeorge vanaf /10.0.0.29 voor pad / hbase op ma 05 maart 22:59:47 CET 2012
……/hbase/.logs/10.0.0.29,60020,1330984111693/10.0.0.29%3A60020.1330984118842 0 bytes, 1 blok(ken), OPENFORWITE:………………………………..Status:GEZOND
Totale grootte:     2088783626 B
Totaal mappen:     54
Totaal bestanden:   45
…

Dit heeft niet direct betrekking op een bezette thread aan de serverzijde, omdat deze worden toegewezen door blok-ID. Maar je kunt er wel uit opmaken dat er één open blok is om te schrijven. Het Hadoop-commando heeft extra opties om de daadwerkelijke bestanden af ​​te drukken en de ID te blokkeren waaruit ze bestaan:

$ hadoop fsck /hbase -files -blocks
FSCK gestart door larsgeorge vanaf /10.0.0.29 voor pad /hbase op di 06 mrt 10:39:50 CET 2012

…
/hbase/.META./1028785192/.tmp