tldr：我有一个pyspark作业，当我在一个有16个vcpu的ec2示例中运行它时，它会在10分钟内完成，但是如果我使用一个有20多个vcpu的示例，它会冻结（它不会失败，只是永远不会完成）。我已经尝试了我能想到的一切，我只是不知道为什么会这样。
完整故事：
我有大约200个小的pyspark作业，出于成本和灵活性的考虑，我使用aws批处理和spark dockers而不是emr来执行。最近，我决定尝试一下这些工作的最佳配置，我意识到一些奇怪的事情：一个用16个或更少的vCPU快速完成（大约10分钟）的工作永远不会以20个或更多的vCPU结束（我等了3个小时）。我首先想到的可能是批处理或ecs代理管理任务的方式有问题，所以我尝试直接在ec2中运行docker，也遇到了同样的问题。然后我认为问题出在docker图像上，所以我尝试创建一个新图像：
第一个使用Spark按照aws胶水兼容版本安装(https://aws-glue-etl-artifacts.s3.amazonaws.com/glue-1.0/spark-2.4.3-bin-hadoop2.8.tgz)
新版本是基于ubuntu20的，安装了apachemirror上的spark(https://apache.mirror.digitalpacific.com.au/spark/spark-$spark\u version/spark-$spark\u version-bin-hadoop$hadoop\u version.tgz）
同样的事情发生了。然后我决定问题出在使用docker上，所以我直接在ec2中安装了所有的东西，得到了相同的结果。试着改变Spark版本，同样的事情也发生了。我想这可能是硬件阻塞了太多线程的问题，所以我切换到amd的一个示例，没有任何改变。尝试修改一些配置，驱动程序使用的内存量，但总是有相同的结果：16 vcpus它工作，超过它，它停止。
其他细节：
根据日志，它似乎总是在同一点停止：在s3上执行parquet读取操作，但是parquet文件非常小（>1mb），所以我不认为这是实际问题。
之后，它有时仍然有日志，但没有什么真正有用的，只是“info contextcleaner:cleaned acculator”。
我使用s3a从s3读取文件。
我没有得到任何错误或Spark日志。
我很感激你在这件事上的任何帮助！