Hadoop 名称节点内存使用情况答案

【问题标题】：Hadoop namenode memory usageHadoop 名称节点内存使用情况
【发布时间】：2012-11-02 09:48:52
【问题描述】：

我对 hadoop namenode 内存问题感到困惑。

当namenode内存使用率高于一定百分比（比如75%）时，通过hadoop api读写hdfs文件会失败（比如调用一些open()会抛出异常），是什么原因?有没有人有同样的事情？ PS.这次namenode磁盘io不高，CPU比较空闲。
什么决定了namenode'QPS（每秒查询）？

非常感谢！

【问题讨论】：

【解决方案1】：

由于 namenode 基本上只是一个 RPC 服务器，管理带有块的 HashMap，因此您有两个主要的内存问题：

Java HashMap 的成本很高，它的冲突解决（单独的链接算法）也很昂贵，因为它将冲突的元素存储在一个链表中。
RPC 服务器需要线程来处理请求 - Hadoop 带有他自己的 RPC 框架，您可以使用 dfs.namenode.service.handler.count 配置它对于数据节点它默认设置为 10。或者您可以配置这个dfs.namenode.handler.count 用于其他客户，如 MapReduce 作业，JobClients 想要运行作业。当一个请求进来并且它想要创建一个新的处理程序时，它可能会耗尽内存（新线程也分配了大量的堆栈空间，也许你需要增加这个）。

这就是你的namenode需要这么多内存的原因。

What determines namenode'QPS (Query Per Second) ?

我还没有对它进行基准测试，所以我不能给你很好的建议。当然，微调处理程序计数高于可以并行运行的任务数 + 推测执行。根据您提交工作的方式，您还必须微调其他属性。

当然，您应该始终为 namenode 提供足够的内存，这样它就有足够的空间来不陷入完整的垃圾回收周期。

【讨论】：

谢谢，我设置dfs.namenode.handler.count = 8000，根据你的回答，会不会花费namnode 8000 * 2M（假设一个线程花费2M）？另外一件事，为什么要读或写当namenode内存使用> 75％时hdfs文件失败？我想不出理由
一般不能这么说，但至少使用 1mb 堆栈，我相信 2mb 是一个很好的上限。
我写了一个程序，需要从hdfs获取很多文件，当namonode内存使用率> 75%时，会发现很多文件无法从hdfs获取