【发布时间】：2019-12-15 14:25:32
【问题描述】：
由于OutOfMemoryError，我的 Cloudera 集群 HDFS Datanodes 反复崩溃：
java.lang.OutOfMemoryError: Java heap space
Dumping heap to /tmp/hdfs_hdfs-DATANODE-e26e098f77ad7085a5dbf0d369107220_pid18551.hprof ...
Heap dump file created [2487730300 bytes in 16.574 secs]
#
# java.lang.OutOfMemoryError: Java heap space
# -XX:OnOutOfMemoryError="/usr/lib64/cmf/service/common/killparent.sh"
# Executing /bin/sh -c "/usr/lib64/cmf/service/common/killparent.sh"...
18551 TS 19 ? 00:25:37 java
Wed Aug 7 11:44:54 UTC 2019
JAVA_HOME=/usr/lib/jvm/java-openjdk
using /usr/lib/jvm/java-openjdk as JAVA_HOME
using 5 as CDH_VERSION
using /run/cloudera-scm-agent/process/3087-hdfs-DATANODE as CONF_DIR
using as SECURE_USER
using as SECURE_GROUP
CONF_DIR=/run/cloudera-scm-agent/process/3087-hdfs-DATANODE
CMF_CONF_DIR=/etc/cloudera-scm-agent
4194304
在分析堆转储时，最大的嫌疑人显然是在 org.apache.hadoop.hdfs.server.datanode.DirectoryScanner 类的 ExecutorService 中排队的数百万个 ScanInfo 实例。
当我检查每个 ScanInfo 可运行对象的内容时，我没有看到任何奇怪的东西：
除了这个和 HDFS 中的块数有点高之外，除了在我的集群中随机崩溃的不同 DataNode 之外，我没有得到任何其他信息。
知道为什么这些对象一直在DirectoryScanner 线程池中排队吗？
【问题讨论】：
-
这种情况经常发生吗？我在运行DataNode Block Scanner 时遇到了类似的问题，并且在处理大量非常小的文件时遇到了一些问题。为了解决这个问题，我们有两个选择：增加内存（注意 31 / 32 GB 边界，其中 java 使用更大的指针，因此突然需要 很多 更多 RAM）或减少小文件的数量（例如通过删除垃圾/合并文件）。
-
嗨@Secespitus，是的，它经常发生。我们有一个合并镶木地板文件的特定工作，但我们不能低于警告阈值的 2 倍。关于内存，我将尝试将其增加到更接近您提到的数字。谢谢！