Question

编辑：注意：执行者通常会发出消息[GC (Allocation Failure) ]。之所以运行它，是因为它试图为执行器分配内存，但是执行器已满，因此它将在向执行器加载新内容时尝试GC，以腾出空间。如果您的执行器循环执行此操作，则可能意味着您要加载到该执行器中的内容太大。

我正在AWS EMR 5.8.0上运行Spark 2.2，Scala 2.11

我正在尝试对拒绝完成的数据集运行count操作。令人沮丧的是，它仅挂在一个特定的文件上。我在与S3不同的文件上运行此作业，没问题-它完全完成了。原始CSV文件本身为@ 18GB，我们对其进行了转换，以将原始CSV转换为结构列，并为其增加了一列。

我环境的核心奴隶是8个实例，每个都是：

r3.2xlarge
16 vCore, 61 GiB memory, 160 SSD GB storage

我的Spark会话设置为：

implicit val spark = SparkSession
      .builder()
      .appName("MyApp")
      .master("yarn")
      .config("spark.speculation","false")
      .config("hive.metastore.uris", s"thrift://$hadoopIP:9083")
      .config("hive.exec.dynamic.partition", "true")
      .config("hive.exec.dynamic.partition.mode", "nonstrict")
      .config("mapreduce.fileoutputcommitter.algorithm.version", "2")
      .config("spark.dynamicAllocation.enabled", false)
      .config("spark.executor.cores", 5)
      .config("spark.executors.memory", "18G")
      .config("spark.yarn.executor.memoryOverhead", "2G")
      .config("spark.driver.memory", "18G")
      .config("spark.executor.instances", 23)
      .config("spark.default.parallelism", 230)
      .config("spark.sql.shuffle.partitions", 230)
      .enableHiveSupport()
      .getOrCreate()

数据来自CSV文件：

val ds = spark.read
          .option("header", "true")
          .option("delimiter", ",")
          .schema(/* 2 cols: [ValidatedNel, and a stuct schema */)
          .csv(sourceFromS3)
          .as(MyCaseClass)

val mappedDs:Dataset[ValidatedNel, MyCaseClass] = ds.map(...)

mappedDs.repartition(230)

val count = mappedDs.count() // never finishes

如预期的那样，它旋转了230个任务，完成了229个任务，除了中间的某个地方。如下所示-第一个任务永远挂起，中间的任务没问题（虽然很奇怪-大小记录/比率非常不同）-其他229个任务看起来与完成的任务完全相同。

Index| ID |Attempt |Status|Locality Level|Executor ID / Host|                       Launch Time          |   Duration   |GC Time|Input Size / Records|Write Time | Shuffle Write Size / Records| Errors
110   117   0   RUNNING     RACK_LOCAL     11 / ip-XXX-XX-X-XX.uswest-2.compute.internal 2019/10/01 20:34:01    1.1 h   43 min     66.2 MB / 2289538                0.0 B / 0   
0     7     0   SUCCESS     PROCESS_LOCAL  9 / ip-XXX-XX-X-XXX.us-west-2.compute.internal 2019/10/01 20:32:10   1.0 s   16 ms      81.2 MB /293        5 ms         59.0 B / 1   <-- this task is odd, but finishes
1     8     0   SUCCESS     RACK_LOCAL      9 / ip-XXX-XX-X-XXX.us-west-2.compute.internal 2019/10/01 20:32:10  2.1 min     16 ms      81.2 MB /2894845        9 s          59.0 B / 1   <- the other tasks are all similar to this one

检查挂起任务的标准，我反复看到以下内容永无止境：

2019-10-01T21:51:16.055+0000: [GC (Allocation Failure) 2019-10-01T21:51:16.055+0000: [ParNew: 10904K->0K(613440K), 0.0129982 secs]2019-10-01T21:51:16.068+0000: [CMS2019-10-01T21:51:16.099+0000: [CMS-concurrent-mark: 0.031/0.044 secs] [Times: user=0.17 sys=0.00, real=0.04 secs] 
 (concurrent mode failure): 4112635K->2940648K(4900940K), 0.4986233 secs] 4123539K->2940648K(5514380K), [Metaspace: 60372K->60372K(1103872K)], 0.5121869 secs] [Times: user=0.64 sys=0.00, real=0.51 secs]

另一个要注意的是，在我调用计数之前，我先打电话给repartition(230)来{@ {1}}，以确保数据的均等分配

这是怎么回事？

Answer 1

它可能与数据偏斜和/或数据解析问题有关。请注意，问题分区的记录要比已成功处理的记录多得多：

Input Size /  Records
66.2 MB / 2289538
81.2 MB /293

我将检查所有分区文件的大小和记录数是否大致相同。在有问题的分区文件或“好的”分区文件中，行和/或列定界符可能已关闭（对于80 MB的文件，293行似乎太低了。）

Spark任务挂在[GC（分配失败）]

1 个答案: