为什么 Spark 作业因“打开的文件太多”而失败？答案

【问题标题】：Why does Spark job fail with "too many open files"?为什么 Spark 作业因“打开的文件太多”而失败？
【发布时间】：2020-06-11 01:56:34
【问题描述】：

我在 Spark 作业的随机播放阶段收到“打开的文件过多”。为什么我的工作会打开这么多文件？我可以采取哪些步骤来尝试使我的工作取得成功。

【问题讨论】：

标签： apache-spark

【解决方案1】：

This has been answered on the spark user list:

最好的方法肯定是尽可能增加ulimit，这是我们在 Spark 中做出的一种假设，即集群将是能够移动它。

你可以通过减少数量来解决这个问题 reducer [或每个节点使用的核心]，但这可能会对您的性能产生一些影响工作。

一般来说，如果集群中的一个节点具有 C 分配的核心并且您运行一个带有 X 减速器的作业，然后 Spark 将并行打开 C*X 文件并动笔。洗牌合并将有助于减少总数创建的文件数量，但文件句柄的数量随时打开时间不会改变，所以它不会帮助解决 ulimit 问题。

-帕特里克·温德尔

【讨论】：

我认为 spark 的主要好处之一是它可以将东西保存在内存中。为什么要打开这么多文件呢？
它在随机播放期间使用这些文件。这个想法是首先将每个 reducer 的数据放在本地磁盘上，然后 reducer 可以按照自己的节奏消费数据（拉而不是推）。
以防其他人使用 mesos 遇到同样的问题，引用相同的 spark 用户列表线程：“事实证明 mesos 可以覆盖 OS ulimit -n 设置。所以我们增加了 mesos slave ulimit -n 设置。”

【解决方案2】：

默认的 ulimit 是 1024，这对于大规模应用程序来说太低了。 HBase 建议最高 64K；现代 linux 系统似乎对这么多打开的文件没有问题。

使用

ulimit -a

查看当前打开文件的最大数量

ulimit -n

可以临时改变打开文件的数量；您需要更新系统配置文件和每个用户的限制以使其永久化。在 CentOS 和 RedHat 系统上，可以在

中找到

/etc/sysctl.conf
/etc/security/limits.conf

【讨论】：

【解决方案3】：

解决此错误的另一种方法是减少分区。

检查您是否有很多分区：

someBigSDF.rdd.getNumPartitions()

Out[]: 200

#if you need to persist the repartition, do it like this
someBigSDF = someBigSDF.repartition(20)

#if you just need it for one transformation/action, 
#you can do the repartition inline like this
someBigSDF.repartition(20).groupBy("SomeDt").agg(count("SomeQty")).orderBy("SomeDt").show()

【讨论】：