使用EC2时实例与核心

Question

在通常被称为“中介数据”项目的工作中，我已经能够将我的代码(主要是用于Python中的建模和预测)并行化到一个4到32个核心的单一系统上。现在，我正在考虑扩展到EC2上的集群(可能是使用Star群集/IPython，但也可以考虑其他建议)，并且对于如何协调实例上的跨核分发工作和集群上的实例进行协调感到困惑。

在每个实例上进行跨实例并行化和跨核并行化是否实用？如果是这样的话，谁能给出一个快速的利弊，运行许多实例，每一个有几个核心与少数几个实例多呢？是否有经验法则来选择每个实例的实例与核心的正确比率？

带宽和RAM在我的项目中是非常重要的，但是当这些是瓶颈和调整时很容易发现。我可以想象，在没有重复测试的情况下，将正确的核心组合测试到实例要困难得多，而且我的项目变化太大，任何单一的测试都不能适用于所有情况。提前谢谢，如果我只是没能正确地搜索到这一条，请随便给我找个其他地方的正确答案！

Answer 1

在使用IPython时，您几乎不需要担心它(代价是损失了一些效率/更大的通信开销)。默认情况下，StarCluster中的并行StarCluster插件将在每个节点上启动每个物理核的一个引擎(我相信这是可配置的，但不确定在哪里)。您只需使用DirectView api (map_sync，apply_sync，.)在所有引擎上运行您想要的任何东西。或者%px魔法命令。如果您已经在一台机器上并行使用IPython，那么在集群上使用它也没有什么不同。

针对你的一些具体问题：

“如何协调实例上的核与集群中的实例之间的分配工作”--每个核心至少有一个引擎；工作自动分布在所有核心和所有实例之间。

“跨实例并行化和在每个实例上跨核并行是否实用？”--是的:)如果您正在运行的代码是令人尴尬的并行(在多个数据集中完全相同)，那么您可以忽略特定引擎运行的位置。如果核心需要引擎之间的大量通信，那么当然需要构造它，以便引擎主要与同一台物理机器上的其他引擎通信；但我认为，这种问题不太适合IPython。

“如果是这样的话，有人能快速分析一下运行多个实例的利弊吗?每个实例都有几个实例，而每个实例都有几个实例?是否有一个经验规则来选择每个实例的实例与核的正确比率？”--使用最大的c3实例进行计算绑定，对于内存带宽限制的问题使用最小的实例；对于消息传递问题，也使用最大的实例，但尝试将问题划分为使每个分区在一台物理机器上运行，并且大多数消息传递都在同一分区内。在N个四倍c3实例上运行比在2N双c3上运行慢得多的问题是罕见的(一个人为的例子可能是在大量图像上运行多个简单的过滤器，您可以遍历每个过滤器的所有图像，而不是相同图像的所有过滤器)。使用最大的实例是一个很好的经验法则。

Answer 2

一个普遍的经验法则是，除非你必须分发，否则不要分发。通常情况下，具有一定容量的N个服务器比2N个容量减半的服务器更有效。更多的数据访问将是本地的，因此内存快而网络慢。

在某一点上，扩大一台机器变得不经济，因为额外资源的成本是线性的。然而，这一点仍然是惊人的高。

特别是在Amazon上，如果您使用现货市场实例，那么每种实例类型的经济性都会有很大的差异。默认定价或多或少意味着，无论实例类型如何，资源成本相同，差异很大；大实例可以比小实例便宜，或者N个小实例可以比具有等效资源的大型机器便宜得多。

这里一个很大的考虑是，当您从一台机器移动到多台机器时，计算范式可能会发生很大的变化。例如，通信开销导致的权衡可能迫使您采用数据并行模式来进行扩展。这意味着不同的工具和算法的选择。例如，SGD在内存中和Python中看起来与在MapReduce上完全不同。因此，在并行化之前，您必须考虑这一点。

为了可靠性，您可以选择跨集群分发工作，即使单个节点和非分布式范例为您工作。如果单个节点失败，则会丢失所有的计算；分布式计算可能会恢复并只完成丢失的部分。

Answer 3

所有被认为是相等的东西(成本、CPU津贴等)您可以选择最小的实例，该实例可以保存内存中的所有数据集并进行扩展。那条路

• 请确保不因网络通信而导致不必要的延迟，以及
• 您倾向于最大化进程的总体可用内存带宽。

假设您正在运行某种交叉验证方案来优化模型的某些元参数，为每个核心分配一个测试值，并根据需要选择多个实例，以尽可能少的回合覆盖所有参数空间。

如果您的数据不适合在一个系统的内存中，您当然需要跨实例分发。然后，这是一个平衡内存延迟(许多实例更好)与网络延迟(更好与较少的实例)之间的问题，但考虑到EC2的性质，我敢打赌，您通常更喜欢使用很少的胖实例。