我通过googledataproc在spark集群上运行hail0.1。
我成功运行了1 tb数据集，导入vcf并写入vds。当我尝试运行3 tb数据集时，使用相同的代码，它报告： SparkException: Job 2 cancelled because SparkContext was shut down 我猜这是oom异常，所以我升级了drive.mem和executor.mem，仍然报告相同的错误，但它确实完成了更多的任务(第一次流产在10000/60000左右，第二次流产在30000/60000左右）
这里有哪些故障排除步骤？我想我的司机和执行人的记忆已经很高了。
第一次群集配置：
Master node
Standard (1 master, N workers)
Machine type
n1-highmem-32
Number of GPUs
0
Primary disk type
pd-standard
Primary disk size
200GB
Local SSDs
0
Worker nodes
4
Machine type
n1-highmem-16
Number of GPUs
0
Primary disk type
pd-standard
Primary disk size
100GB
Local SSDs
1
Secondary worker nodes
10
Machine type
n1-highmem-16
Number of GPUs
0
Primary disk type
pd-standard
Primary disk size
100GB
Local SSDs
0
Preemptible
true
Properties
distcp:mapreduce.map.java.opts
-Xmx1664m
distcp:mapreduce.map.memory.mb
2048
distcp:mapreduce.reduce.java.opts
-Xmx1664m
distcp:mapreduce.reduce.memory.mb
2048
hdfs:dfs.namenode.handler.count
80
hdfs:dfs.namenode.service.handler.count
40
hdfs:dfs.replication
1
mapred-env:HADOOP_JOB_HISTORYSERVER_HEAPSIZE
4000
mapred:mapreduce.map.cpu.vcores
1
mapred:mapreduce.map.java.opts
-Xmx3276m
mapred:mapreduce.map.memory.mb
4096
mapred:mapreduce.reduce.cpu.vcores
2
mapred:mapreduce.reduce.java.opts
-Xmx8192m
mapred:mapreduce.reduce.memory.mb
10240
mapred:yarn.app.mapreduce.am.command-opts
-Xmx8192m
mapred:yarn.app.mapreduce.am.resource.cpu-vcores
2
mapred:yarn.app.mapreduce.am.resource.mb
10240
spark-env:SPARK_DAEMON_MEMORY
4000m
spark:spark.driver.extraJavaOptions
-Xss4M
spark:spark.driver.maxResultSize
60g
spark:spark.driver.memory
200g
spark:spark.executor.cores
8
spark:spark.executor.extraJavaOptions
-Xss4M
spark:spark.executor.memory
37237m
spark:spark.kryoserializer.buffer.max
1g
spark:spark.task.maxFailures
20
spark:spark.yarn.am.memory
37237m
spark:spark.yarn.am.memoryOverhead
3723
spark:spark.yarn.executor.memoryOverhead
3723
yarn-env:YARN_NODEMANAGER_HEAPSIZE
4000
yarn-env:YARN_RESOURCEMANAGER_HEAPSIZE
4000
yarn-env:YARN_TIMELINESERVER_HEAPSIZE
4000
yarn:yarn.nodemanager.resource.memory-mb
81920
yarn:yarn.scheduler.maximum-allocation-mb
81920
yarn:yarn.scheduler.minimum-allocation-mb
2048第二次升级主节点到n1-highmem-96，工作节点到n1-highmem-32，spark.driver.memory 600g，spark.driver.maxresultsize 180g，其他一套都是通过Yarn自动调整的。
1条答案
按热度按时间pzfprimi1#
你的工作的需要取决于工作做什么，例如它是否进行重新分区、分组或按键缩减等。
在可伸缩配置的作业中，理想情况下运行驱动程序的主程序不需要大量内存。一些常见的陷阱有时会导致主节点占用大量空间：
意外显式设置
.setMaster("local[*]")在您的spark代码中，可能是本地测试目的的延迟——这将告诉spark以单节点模式运行，即使有完整的分布式集群可用在大型分布式数据集上调用“collect（）”
在任何分布式Dataframe或rdd操作之外的主程序中执行显式处理逻辑。
您应该确保您的工作人员实际上得到了分配给他们的任何工作，而不是仅仅因为上面列出的原因之一而在主节点中受到限制。
如果您的工作人员确实在工作，则可能不是主节点导致问题。看看您的配置，您的磁盘对于数据集大小来说似乎非常小。如果一个作业绝对是“只Map”的，这有时是可以的，但是在几乎所有的情况下，从成本的Angular 来说，你最好在所有节点上添加更大的磁盘，因为google计算引擎的磁盘性能会随着它的大小而增加。而且由于即使是2000gb的pd标准每小时的成本也仅相当于大约2个CPU，如果您运行的是非常大的机器，比如96核highmem示例，从长远来看，消除任何磁盘性能瓶颈几乎肯定会为您节省时间和金钱（例如，在96核的机器上，从100gb到2000gb甚至可以提高2%的性能，额外的磁盘成本比自己付出的成本还要高）。
如果发生任何重新分区、分组等情况，那么您的工作人员将依赖本地磁盘来获得暂存/洗牌空间。在这种情况下，如果总磁盘空间小于洗牌数据的必要工作集，则作业将不会成功。总的来说，将所有节点上的磁盘空间增加到2000gb可能是解决方案。