tldr：在hadoop版本更改之后，jobs开始被oomkilled。
我在ecs上运行了很多小的pyspark作业，最近由于受到限制，我不得不从hadoop2.7改成一个更新的版本。更改后我注意到的一件事是，在代码没有任何其他更改的情况下，我的内存开始被ecs代理终止，因此现在一个以前可以在20gb内存下正常运行的作业有时会在80gb内存下失败。我试过hadoop版本3.0和3.2，以及spark 2.4.7和3.1.1，同样的事情总是发生。
我在配置中唯一更改的是在下面添加了这两个，因为更改后出现了“打开文件过多错误”。
spark.shuffle.consolidatefiles true spark.sql.shuffle.300分区
其他的东西，比如驱动内存和执行内存是一样的。在计算作业可以使用的最大内存量时，除了spark.executor.memory、spark.driver.memory、spark.driver.memoryoverhead和spark.executor.pyspark.memory之外，还有什么我应该考虑的吗？这两种配置会是罪魁祸首吗？如果是这样的话，如何避免在没有它们的情况下打开过多的文件？
谢谢你的帮助！
编辑：所以，我知道发生了什么。aws太差劲了，现在由于某种原因，它没有设置你在将批处理作业提交回ecs时为内存选择的值（使用前端和api）。相反，它对作业定义使用默认值。所以，我的新版本的作业定义是用低内存创建的，因为我想“嘿，我可以为每个作业设置这个，所以不需要在默认情况下将其设置为高”，这导致了一切。不确定这是否在每个地区都发生，也不确定这种情况会持续多久，但俄勒冈州现在的情况就是这样。
我从中学到的是：在重做你的工作之前，一定要首先考虑aws做了一些奇怪的事情的可能性。