集群上的 Ipyparallel 模块加载速度极慢

Ipyparallel module load on a cluster extremely slow

我创建了一个由 host0host47 组成的 48 节点集群(所有节点都是 g2.2xlarge Amazon EC2 实例 no网络文件系统)。 根据 https://ipyparallel.readthedocs.io/en/latest/process.html, I have created a controller on host0 and 47 engines on host1 to host47. I have replicated most of the configuration for the ssh ipyparallel cluster from the StarCluster 项目(但是,正如我所说,没有 NFS)。 集群工作并且似乎产生了正确的结果,但加载模块有时需要很长时间。 例如,

import ipyparallel as ipp
client = ipp.Client('/path/to/ipcontroller-client.json',sshkey='mykey')
view = client[:]
view.block=True

with view.sync_imports():
    import time
    import numpy
    from keras.models import Sequential
    from keras.layers import Dense, Dropout
    from keras.regularizers import l1
    from keras.optimizers import SGD
    from subprocess import check_output

需要 30 多分钟才能完成。如果我更改为 block=Falseview.wait(),这不会改变。同样使用 view.execute("import time; import numpy; import keras.models ...") 也无济于事。我知道加载 keras 模块有点慢,但在我的本地机器上通常不到 1 分钟即可完成。我已经尝试了 picklejson(未)打包。 我应该提到,当我使用 same 集群进行另一次计算时,模块的加载工作正常。我猜加载的模块缓存在某个地方。但是当我终止实例、创建新实例并配置新的 ipyparallel 集群时,我在模块加载方面遇到了同样的问题。

查看ipcontroller日志,发现大部分请求对应sync_imports

2016-08-25 12:12:02.310 [IPControllerApp] queue::client '\x00"_\x0b\x0b'
submitted request '46244cf0-ad0a-4748-a84c-8d3d69d8252c' to 0

几分钟内完成。但是,其中一些需要大约 30 分钟。请参阅以下 complete_time - submit_time 的直方图,该直方图源自 ipcontroller 日志。

我最近才开始使用 python,我不知道这里可能有什么问题。似乎完成时间和提交时间之间的最大时间差随着集群大小的增加而增加。 非常欢迎任何指向可能问题的指示。

顺便说一句:我正在使用 Python 2.7.6 和 Ipyparallel 5.1.1

我目前最好的猜测是问题是由 EBS 卷的初始化引起的——有时可能会有点慢。 集群实例总是从图像开始,并在计算完成后立即终止。从快照创建的 EBS 卷必须从 S3 获取数据。参见 AWS EBS documentation

New EBS volumes receive their maximum performance the moment that they are available and do not require initialization (formerly known as pre-warming). However, storage blocks on volumes that were restored from snapshots must be initialized (pulled down from Amazon S3 and written to the volume) before you can access the block. This preliminary action takes time and can cause a significant increase in the latency of an I/O operation the first time each block is accessed. For most applications, amortizing this cost over the lifetime of the volume is acceptable. Performance is restored after the data is accessed once.