Question

我正在尝试使用appengine-mapreduce准备加载到BigQuery中的数据，并且正在运行内存限制。我正在使用CloudStorage，因此this question中可接受的响应可能不适用。

我所看到的是，单个VM实例（似乎是整个映射器任务的协调器）超过了分配给它的~1GB，然后在任何工作人员启动之前被杀死。在此屏幕截图中，有三个实例，只有顶部实例在内存中增长： enter image description here

在之前的几次尝试中，有多达12个实例，除了一个以外的所有实例都在内存限制之内，只有一个达到极限并被杀死。这告诉我，没有一般的内存泄漏（可能是在Guido van Rossum在早期问题中建议定期调用gc.collect()），而是在处理和工作的文件的大小和数量之间不匹配关于appengine-mapreduce代码中文件大小和计数的假设。

在上面的例子中，有12个.zip文件被传递给作业进行处理。最小的.zip文件压缩约12 MB，最大压缩45 MB。以下是我传递给MapperPipeline的配置：

output = yield mapreduce_pipeline.MapperPipeline(
    info.job_name,
    info.mapper_function,
    'mapreduce.input_readers.FileInputReader',
    output_writer_spec='mapreduce.output_writers.FileOutputWriter',
    params={
        'input_reader': {
            'files': gs_paths,
            'format': 'zip[lines]',
        },
        'output_writer': {
            'filesystem': 'gs',
            'gs_bucket_name': info.results_dirname,
            'output_sharding': 'none',
        },
    },
    shards=info.shard_count)

在这种情况下，shard_count的值为16。

这是熟悉的情况吗？我能做些直截了当的事情来避免达到1GB的内存限制吗？（this question的海报可能没有得到答复，但也遇到了类似的问题。）

Answer 1

我能够克服第一个障碍，协调员因为内存不足而被杀死，使用大约1-6MB的文件并将碎片计数增加到96个碎片。以下是我之后学到的一些事情：

分片计数与实例数大致不等，但可能相当于工作人员数。稍后，我有多达200多个碎片，约旋转了30个实例。
当协调器被杀死时，内存管理并不那么重要，但是后来，当辅助实例内存不足时。
如果过于频繁地致电gc.collect()，则吞吐量会大幅下降。如果你称它太少，实例就会被杀死。
正如我猜测的那样，要处理的文件数量，单个文件大小，指定的分片数量，垃圾收集发生的频率以及最大可用内存之间似乎存在复杂的关系。一个实例，所有实例都必须兼容才能避免进入内存限制。
AppEngine基础架构似乎经历了高利用率时期，由于appengine-mapreduce处理的堆栈部分的HTTP超时，之前工作的开始失败。

与内存相关的调优似乎特定于上传的数据量。我感到悲观的是，对于我需要处理的所有不同表格，我们会直截了当地制定一个通用的方法，每个表格都有不同的聚合大小。到目前为止，我能够处理的最多是140 MB压缩（可能是1-2 GB未压缩）。

对于任何尝试此操作的人，以下是我记录的一些数字：

Chunk    Shards  Total MB  MB/shard  Time   Completed?  Total memory         Instances  Comments
daily    96      83.15     0.87      9:45   Yes         ?                    ?
daily    96      121       1.2       12.35  Yes         ?                    ?
daily    96      140       1.5       8.36   Yes         1200 MB (s. 400 MB)  24
daily    180     236       1.3       -      No          1200 MB              ?
monthly  32      12        0.38      5:46   Yes         Worker killed        4
monthly  110     140       1.3       -      No          Workers killed       4          Better memory management of workers needed.
monthly  110     140       1.3       -      No                               8          Memory was better, but throughput became unworkable.
monthly  32      140       4.4       -      No          Coordinator killed   -
monthly  64      140       2.18      -      No          Workers killed       -
daily    180     236       1.3       -      No          -                    -          HTTP timeouts during startup
daily    96      140       1.5       -      No          -                    -          HTTP timeouts during startup

在启动appengine-mapreduce作业期间超出了单个实例的内存限制

1 个答案: