Когда наш резервный namenode на основе hadoop v2.4.1 перезапустился с отказа, мы обнаружили, что namenode был слишком занят, чтобы отвечать на него после его выхода из safemode. Мы сбросили несколько стеков, все они выглядели так: Перезапущенный namenode страдает от блочного отчета storm
Thread 212 (IPC Server handler 148 on 8020): State: WAITING Blocked count: 66 Waited count: 598 Waiting on [email protected] Stack: sun.misc.Unsafe.park(Native Method) java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834) java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867) java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197) java.util.concurrent.locks.ReentrantLock$FairSync.lock(ReentrantLock.java:229) java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:290) org.apache.hadoop.hdfs.server.namenode.FSNamesystem.writeLock(FSNamesystem.java:1378) org.apache.hadoop.hdfs.server.blockmanagement.BlockManager.processReport(BlockManager.java:1676) org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.blockReport(NameNodeRpcServer.java:1019) org.apache.hadoop.hdfs.protocolPB.DatanodeProtocolServerSideTranslatorPB.blockReport(DatanodeProtocolServerSideTranslatorPB.java:152) org.apache.hadoop.hdfs.protocol.proto.DatanodeProtocolProtos$DatanodeProtocolService$2.callBlockingMethod(DatanodeProtocolProtos.java:28061) org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:585) org.apache.hadoop.ipc.RPC$Server.call(RPC.java:928) org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2013) org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2009) java.security.AccessController.doPrivileged(Native Method) javax.security.auth.Subject.doAs(Subject.java:415) org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1556) org.apache.hadoop.ipc.Server$Handler.run(Server.java:2007)
Почти все обработчики серверов ждут, когда FSNameSystem # writeLock обрабатывает инкрементные/полные отчеты!
Conf:
dfs.blockreport.initialDelay: 120.
dfs.blockreport.intervalMsec: 6h.
сервер обработчиков номер: 200.
datanodes number: 400.
Наменода занимает 0,5-1 с для обработки отчета блока.
логарифм DataNodes увидеть много offerService IOExceptions и повторами.
Бревно NN показали, что хранение в DataNode было обработано более чем в два раза, а некоторые даже до 10.
blockLog.info("BLOCK* processReport: from storage " + storage.getStorageID() + " node " + nodeID + ", blocks: " + newReport.getNumberOfBlocks() + ", processing time: " + (endTime - startTime) + " msecs");
Кто-нибудь видел такую же проблему, любые идеи?
Сколько у вас данных? –
Спасибо за ваш ответ. У нас есть 400 datanodes. – Dengzh
Я думаю, что проблема связана с conf dfs.blockreport.initialDelay. – Dengzh