这个问题引起了我的注意，因为我们的spark集群中的许多作业最近都失败了。并且它们的日志显示"；在丢失节点上释放的容器"；消息。当检查发生执行器丢失的节点时，yarn nodemanager中的高空间使用率引起了我的注意。(以下所有测试都是在一个火花节点上完成的(E.g，
df -h | grep /hadoop/yarn/nm-local
告诉我目录的使用量是800G(占总可用空间的75%(
根据我的理解，该目录用于spark集群的shuffle空间。作业完成后应释放其空间使用情况。但是，即使集群中没有运行作业，其使用率仍然很高。当探测哪些文件导致高使用率时，奇怪的事情发生了：
du -h --max-depth=1 /hadoop/yarn/nm-local
告诉我所有的文件加起来只有80G。显然800G与80G不一致。有一种理论可以解释，du不包括正在删除的文件或正在运行的进程仍在使用的已删除文件。所以我检查了与该目录相关的所有运行进程：
lsof | grep "/hadoop/yarn/nm-local"
但当前运行的进程使用的所有文件加起来并没有达到800GB，甚至没有关闭。你能帮我弄清楚这种差异是从哪里来的吗？
我想你说的是本地化缓存。。
这些文件是用纱线定期清理的。(yarn.nodemanager.localizer.cache.cleanup.interval-ms(
如果您在两者之间存在差异时发现问题，您可能需要缩短清理间隔。这可能有帮助，也可能没有帮助，因为问题可能是您有很多文件写入争用。(大多数性能问题的原因。(
您可能希望考虑以下选项：
- 更改
yarn.nodemanager.local-dirs以写入其自己的独立驱动器(无争用驱动器( - 向本地化程序添加额外的驱动器以减少争用(最好使用多个驱动器而不是一个驱动器(
- 将线程/RAM添加到本地化程序中(只有在写/读不是问题的情况下才会有所帮助，如果磁盘争用是问题的根源，实际上会让情况变得更糟。这就是我报道它的原因。(