我在2节点（1 worker 1 master）spark群集上运行基本排序程序（textFile（），sortBy（），saveAsTextFile（）），并且任务的执行时间变化很大。这两个作业是sortBy（）和saveAsTextFile（），第一个作业大约需要一分钟，大小可达100GB，而saveAsTextFile占用的时间要长得多（根据文件大小，在2到15分钟之间）。
对我来说有趣的是，saveAsTextFile作业的任务执行时间为每个任务2-10秒，而sortBy作业需要几毫秒。
我一直试图通过查看iostat和top的输出来找到saveAsTextFile作业的潜在瓶颈。另外，在命令行驱动程序中，第二个作业在spurts中完成;这是16个任务将立即完成（工人有16个核心），然后暂停几秒钟，然后16再次完成。这表明某些东西正在阻碍任务执行时间（可能是cpu？），但从查看监控命令行工具看，似乎没有任何东西可以充分利用。 Executor内存设置为ram的3/4，但top读取spark执行器进程从不占用超过50％。类似地，iostat读取％idle在15-35之间用于cpu利用率，而％iowait总是小于5（表示没有线程在磁盘io上等待）。此外，网络延迟不应成为问题，因为只有一个工作节点。
我已经搞乱了spark.storage.memoryFraction，spark.local.dir，spark.shuffle.file.buffer设置，但saveAsTextFile阶段的任务执行时间仍然需要2-10秒。是什么给了什么？