【问题标题】:How to tune SparkPageRank example application for shorter garbage collection?如何调整 SparkPageRank 示例应用程序以缩短垃圾收集时间?
【发布时间】:2017-07-01 08:48:28
【问题描述】:

我在 7 节点集群中运行 Spark 应用程序 - 亚马逊 EC2 机器上的 1 个驱动程序和 6 个执行程序。我使用 6 个 m4.2xlarge 实例,每个实例有 1 个执行器。它们每个有 8 个内核。该驱动程序位于具有 4 个内核的 m4.xlarge 虚拟机上。 spark版本是2.1.1。

我使用以下命令启动SparkPageRank 应用程序。

spark-submit \
  --name "ABC" \
  --master spark://xxx:7077 \
  --conf spark.driver.memory=10g \
  --conf "spark.app.name=ABC" \
  --conf "spark.executor.extraJavaOptions=-XX:+UseG1GC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:ConcGCThreads=5" \
  --class org.apache.spark.examples.SparkPageRank \
  --executor-memory 22g \
  /home/ubuntu/spark-2.1.1/examples/target/scala-2.11/jars/spark-examples_2.11-2.1.1.jar /hdfscheck/pagerank_data_11G_repl1.txt 4

使用这些配置的 GC 时间确实很长。

这是其中一个执行器的 GC 日志块:

1810.053: [GC pause (GCLocker Initiated GC) (young), 0.1694102 secs]
   [Parallel Time: 167.8 ms, GC Workers: 8]
      [GC Worker Start (ms): Min: 1810053.2, Avg: 1810053.3, Max: 1810053.4, Diff: 0.1]
      [Ext Root Scanning (ms): Min: 0.2, Avg: 0.4, Max: 0.7, Diff: 0.5, Sum: 2.9]
      [Update RS (ms): Min: 12.4, Avg: 12.7, Max: 13.2, Diff: 0.7, Sum: 101.4]
         [Processed Buffers: Min: 11, Avg: 12.9, Max: 16, Diff: 5, Sum: 103]
      [Scan RS (ms): Min: 29.4, Avg: 29.8, Max: 30.1, Diff: 0.7, Sum: 238.7]
      [Code Root Scanning (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0]
      [Object Copy (ms): Min: 124.5, Avg: 124.6, Max: 124.7, Diff: 0.1, Sum: 996.9]
      [Termination (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0]
         [Termination Attempts: Min: 1, Avg: 2.2, Max: 5, Diff: 4, Sum: 18]
      [GC Worker Other (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.1]
      [GC Worker Total (ms): Min: 167.5, Avg: 167.5, Max: 167.6, Diff: 0.1, Sum: 1340.2]
      [GC Worker End (ms): Min: 1810220.8, Avg: 1810220.8, Max: 1810220.8, Diff: 0.0]
   [Code Root Fixup: 0.0 ms]
   [Code Root Purge: 0.0 ms]
   [Clear CT: 0.4 ms]
   [Other: 1.2 ms]
      [Choose CSet: 0.0 ms]
      [Ref Proc: 0.5 ms]
      [Ref Enq: 0.0 ms]
      [Redirty Cards: 0.4 ms]
      [Humongous Register: 0.0 ms]
      [Humongous Reclaim: 0.0 ms]
      [Free CSet: 0.1 ms]
   [Eden: 992.0M(960.0M)->0.0B(960.0M) Survivors: 160.0M->160.0M Heap: 14.6G(22.0G)->13.8G(22.0G)]
 [Times: user=1.34 sys=0.00, real=0.17 secs]

(更多https://pastebin.com/E5bbQZgD

我只能看到并发标记结束花费大量时间的可疑之处。

如果有人能告诉我如何针对这种特殊情况调整垃圾收集,我将不胜感激。 driver节点所在的VM内存16GB,executor VM内存32GB。

【问题讨论】:

标签: performance apache-spark garbage-collection


【解决方案1】:

(不是真正的答案,只是提供帮助的提示集合)。

我的驱动节点有 16GB 内存

如果你用spark.driver.memory=10g 执行了spark-submit,我认为情况并非如此。

您应该改用--driver-memory(这只是一个快捷方式,但让事情更容易记住):

--driver-memory MEM 驱动内存(例如1000M,2G)(默认:1024M)。

关于您的主要问题,GC 的大量使用似乎是 PageRank 算法的工作原理。请注意 Shuffle Write 的大量使用,而 Input 并没有那么大。

我也觉得GC时间没有Task Time那么长。

我担心 RDD 块只有 2,因为这似乎表明并行度非常低,但这可能是它应该如何工作的。


运行示例 SparkPageRank

下面可以用简单的run-example SparkPageRank代替(如Spark的Where to Go from Here中所述)

spark-submit ... \
  --class org.apache.spark.examples.SparkPageRank ... \
  /home/ubuntu/spark-2.1.1/examples/target/scala-2.11/jars/spark-examples_2.11-2.1.1.jar

【讨论】:

  • 什么时候说16/32GB,我的意思是驱动节点所在的VM有16GB的内存,而executor的VM有32GB的内存。已相应地对其进行了编辑
  • 另外,如果我的理解正确的话,任务的gc时间是包含在计算任务的时间里的。也就是说,垃圾收集是阻塞的。在这种情况下,我有各种任务,任务持续时间为 1.6 分钟,相关的 gc 时间为 1.1 分钟。那不应该算长吗?
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2011-08-25
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2018-01-06
  • 2011-07-03
相关资源
最近更新 更多