内存密集型工作在多核云实例(ec2,gce,rackspace)上的扩展性很差？

Question

在扩展使用云实例上的所有内核时,有没有其他人注意到可怕的性能有些内存紧张的工作(在我的情况下为2.5GB)？

当我在我的四核至强芯片上本地运行作业时,使用1核和所有4核之间的差异是所有核心减慢约25%.这是我所理解的; 随着内核耗尽,时钟速率下降是多核芯片设计的一部分.

但是,当我在多核虚拟实例上运行作业时,我看到使用1核和所有核之间的处理时间减少了2x - 4x.我在GCE,EC2和Rackspace实例上看过这个.我测试了许多不同的实例类型,大多数是最快的.

因此,其他人在内存使用量相同的情况下会看到这种行为吗？

我正在运行的工作是用fortran编写的.我没有写它们,我不是一个真正的强人,所以我对它们的了解是有限的.我知道他们的I/O需求很低.当我在跑步时看顶部时,它们似乎是CPU限制的.它们在不需要彼此通信的情况下运行,即,令人尴尬的并行.它们每个内存大约需要2.5GB.

所以到目前为止我最好的猜测是,占用这么多内存的工作会受到虚拟化层内存管理的巨大冲击.也可能是我的工作正在竞争I/O资源,但据专家称,这似乎不太可能.

我现在的解决方法是使用GCE,因为他们拥有的单核实例实际上可以像笔记本电脑的芯片那样快速地运行作业,并且几乎按核心价格成比例.

Answer 1

您可能会遇到内存带宽限制，具体取决于您的数据访问模式。

Linuxperf工具可能会对此提供一些见解，但我承认我并不完全理解您对问题的描述。如果我理解正确的话：

1. 在笔记本电脑上运行一份单线程程序需要 X 分钟才能完成。

2. 在笔记本电脑上运行 4 个单线程程序副本，每个副本需要 X * 1.25 分钟才能完成。

3. 在各种云实例上运行单线程程序的一份副本需要 X 分钟才能完成。

4. 在N核虚拟云实例上运行单线程程序的N个副本，每个副本需要X * 2-4分钟才能完成。

如果是这样，听起来您要么遇到了内核争用，要么遇到了内存 I/O 争用。看看各种 Fortran 编译器选项是否有助于优化内存访问模式将会很有趣；例如，启用 SSE2 加载/存储内在函数或其他优化。您还可以将结果与 gcc 和 intel 的 fortran 编译器进行比较。