所以我们有一个非线程安全的应用程序。 它正在使用的一些库正在对文件系统级别进行锁定。不幸的是，它没有正常工作，如果有一些并发使用的库会崩溃并抛出错误。我们也无法切换这个库。要实现并发，哪一个更好？在一台功能强大的机器上运行100个容器或将其分成100个小型机器？
由于我们正在使用亚马逊，我正在考虑100个X t2.micro实例，每个实例运行一个容器VS一个带有100个docker容器的c4.8xlarge机器。我们对记忆没有任何问题。任务受CPU限制。但它也不是那么重，以至于t2.micro实例足以处理它，只要它一次只处理一个。
我和一位同事讨论了哪一个更好。我更喜欢100个实例，因为我认为Docker隔离将是一个重大的开销。这就像你只有一个资源，但它分为100个需要使用资源的人。另一方面，我的同事提出了一些我认为可能有效的观点。创建Linux命名空间比启动整个操作系统要轻。因此，如果我们有100台机器，我们有100台操作系统，而使用大型机器，我们只有1台操作系统。
问题是，我不知道哪一个是正确的。有知识的人可以解释哪一个会更好并给我一个具体的理由吗？
由于我意识到我刚问了一个不好的问题，我将尝试在此处添加更多信息。为了使问题更加准确，我并不是真的要问哪一个在我的特定用例中更好，哪个更便宜。这只是一个好奇心，在CPU方面表现更好。想象一下，我们有一个非常大的计算问题，我们必须做100个。我们想要并行化它们，但它们不是线程安全的。在100台小型机器或1台100台容器的强大机器中进行它们会更好吗？哪一个会更快完成，为什么？
如果我们只有一台功能强大的机器，那么所有这100个容器都不会争夺资源并减缓整个过程吗？如果它是100台小型机器，由于操作系统或其他因素，整体性能可能会更慢？无论如何，我对此没有任何经验。当然我可以试试这个，但最后，因为它不是理想的环境（有很多因素），结果不管怎样都不具有权威性。我一直在寻找那些知道两种情况如何在低级别工作的人的答案，并且可以论证哪种环境能够更快地完成任务。
答案 0 :(得分：14)
唯一适当的＆＃34;回答你的问题是：你必须测试两个选项，找出哪个更好。原因是：您运行的是一个非常特定的应用程序，具有非常特定的工作负载和非常具体的要求。任何没有实际测试的推荐都是猜测。也许是一个受过教育的猜测＆＃34;，但不会超过这个。
那就是说，让我告诉你在对这种情况进行分析时我会考虑什么。
码头开销应该是绝对最小的。该工具＆＃34; docker＆＃34;它本身没有做任何事情 - 它只是使用常规的Linux内核功能为您的应用程序创建一个独立的环境。
操作系统启动后会消耗一些内存，为真。但操作系统本身的CPU消耗应该可以忽略不计（即使对于非常小的实例）。既然你提到你没有任何内存问题，我们似乎可以假设这个＆＃34; OS开销＆＃34;你的同事提到的也可能是微不足道的。
如果您考虑路线＆＃34;很多非常小的实例＆＃34;，您还可以考虑使用最近发布的 t2.nano实例类型。您需要测试它是否有足够的资源来实际运行您的应用程序。
如果您考虑路线＆＃34;一个非常大的实例＆＃34;，您还应该考虑c4.8xl实例。这应该会比c3.8xl提供更多的CPU功率。
成本分析（us-east-1的价格）：
现在让我们分析每次设置所拥有的资源量。我只关注CPU并忽略内存，因为你提到你的应用程序并不是内存饥渴：
最后，让我们分析每个资源的成本
如您所见，较大的实例通常提供较高的计算密度，通常较便宜。
你还应该考虑这样一个事实，即T2实例可以突破＆＃34;，因为它们可以超过基线性能（如上所述的10％和5％），具体取决于多少＆ ＃34; CPU学分＆＃34;他们有。但是，您应该知道，尽管他们从一些信用余额开始，但它通常足以启动操作系统而不是更多（如果您不这样做，那么随着时间的推移，您会累积更多的CPU信用额度＆＃39 ; t推动你的CPU超出你的基线，但似乎它不是这里的情况，因为我们正在优化性能......）。正如我们所看到的，每个资源的成本＆＃34;几乎是8xl实例的3倍，所以你得到的这个短暂的爆发可能不会改变这个粗略的估计。
您可能还需要考虑网络利用率。应用程序网络密集吗？延迟要求，带宽要求或每秒数据包数量？
现在，弹性怎么样？这些工作对时间敏感度如何？不能及时完成它们的成本是多少？＃34 ;?您可能还想考虑一些失败模式：
减少单个实例死亡的影响＆＃34;在您的工作负载上，仍然可以从更高密度的计算（即大型c3或c4实例）中获得一些好处，您可以考虑其他选项，例如：2x c4.4xl或4x c4.2xl，依此类推。请注意，c4.8xl的成本是c4.4xl的两倍，但它包含两倍以上的vCPU数量。所以上面的分析不会是“线性的”，你需要重新计算一些费用。
假设你对实例没问题＆＃34;失败＆＃34;并且您的应用程序可以以某种方式处理 - 另一个有趣的要点是使用竞价型实例。使用竞价型实例，您可以为价格命名。如果＆＃34;市场价格＆＃34; （由报价 - 需求监管）低于您的出价，您获得实例并仅支付＆＃34;市场价格＆＃34;。如果价格波动高于您的出价，那么您的实例将被终止。与On Demand相比，看到高达90％的折扣并不罕见。截至目前，一个AZ的c3.8xl约为0.28 $ / h（比按需减少83％），一个AZ的c4.8xl大致相同（也减少了83％）。现货定价不适用于t2实例。
您还可以考虑 Spot Block ，其中您说明要运行实例的小时数，您通常需要支付30％ - 比On Demand少45％没有冒险的风险＆＃34; out bided＆＃34;在您指定的期间。在此期间之后，您的实例将被终止。
最后，我会尝试调整服务器的数量，以便在接近整整几个小时的时间内满足它们的需求。 （但不超过该数字）（除非我需要完成执行 ASAP ）。也就是说，拥有一个能够在50分钟内完成工作的小型车队比在10分钟内完成工作的更大车队要好得多。原因是：您按小时，小时开始付款。此外，拥有一个能够在50分钟内完成工作的大型车队通常要比在需要1小时05分钟的小型车队中更好 - 再次，因为您按小时付款，在小时开始时。
最后，你提到你正在寻找＆＃34;最佳表现＆＃34;。你到底是什么意思？您的关键绩效指标是什么？您想优化以减少总花费的时间吗？也许减少每个单位的时间＆＃34; /＆＃34;每个职位＆＃34;？你想减少你的成本吗？您是否正在努力提高能源效率＆＃34;并减少你的碳足迹？或者可以针对所需的维护量进行优化？或者专注于简化以减少其他同事在能够维护解决方案之前需要知识不足的上升时间？
上述许多绩效指标的组合可能？他们将如何结合？总是需要权衡......
正如您所看到的，没有明确的获胜者。至少没有关于您的应用程序和优化目标的更具体信息。这就是为什么大多数时候任何性能优化的最佳选择都是真正测试它的原因。测试通常也很便宜：它可能需要几个小时的工作来设置您的环境，然后可能不到2美元/小时的测试。
所以，这应该给你足够的信息来开始调查。
快乐测试！
答案 1 :(得分：0)
仅基于EC2实例的CPU
t2.micro小于c4.8xl t2.small小于2/3＆＃39> t2.large可能会越来越近了。 c4.8xl很可能会更快，但是没有人可以权威地说出这一点。作为Bruno starts with，您需要在两种实例类型上通过应用程序运行工作负载才能查看。有1000个变量可能会影响结果。没有直接的理由你不能在linux主机上运行100个容器/进程，它已经做了很长时间的多核，多进程。可能会有一些简单的系统限制需要随时调整（ulimit -a和sysctl -a）。另一方面，您的应用程序中可能会有一些内容在此设置中执行得非常糟糕。
在单实例和多实例设置中运行容器时，任何Docker开销几乎都会取消。您在此领域可以改进的任何内容都将有助于限制您在共享主机上遇到的问题。 IBM发布了一篇很棒的报告An Updated Performance Comparison of Virtual Machines and Linux Containers，详细说明了Docker的开销。
net=host。 许多Docker容器的一个重要区别是VM的进程调度程序上的工作负载将完全不同。在运行更多容器时，它不一定会变得更糟，但是你正在进行更少的测试＆＃34;领土。您更少依赖运行在硬件上的Xen虚拟机管理程序，而更多地依赖于在VM内部运行的Linux内核，以便使用两种完全不同的算法进行调度。同样，Linux能够运行许多进程并处理争用，但您只能通过测试找到应用程序的答案。
所以完全猜测，不要以任何方式考虑您的应用程序，纯粹基于通用机器规格和CPU繁重的工作负载。
c4.8xl应该比t2.nano和t2.micro设置更快。t2.small可能会接近。t2.large s，包含2个容器，可能会等同。m3.mediums会突然闪现。 c4.8xl将为您提供专用于您应用的每个流程/主题的最快处理器超级线程。tl; dr 全部测试。使用最快。
答案 2 :(得分：0)
在一般情况下，我会使用docker。仅仅因为添加/更改/删除节点以及进行负载平衡更容易，更快捷。我在这里假设您不需要100个节点，而是需要更改它们的数量。
设置速度也快得多。有一个名为docker swarm https://docs.docker.com/swarm/overview/的东西，我确信它值得研究。此外，如果你不能在一台物理机器上放置100或1000或10000个容器（VM甚至？），你也可以使用覆盖网络https://docs.docker.com/engine/userguide/networking/dockernetworks/#an-overlay-network分发它
编辑：在重新阅读问题之后，您似乎想要一个更具表现性的答案。没有测试就很难说（如果不是不可能的话）。随着表现总是有一些警告和你无法想到的事情（简单地说是人类的:)）。 再次设置100或3或999999台机器比设置相同数量的泊坞机容器要多得多。我知道容器/图像术语仍然混淆，所以只是为了澄清 - 你将创建一个docker镜像，这是一些工作，而不是在N个实例（它是容器）中运行它。如果我错了，请有人纠正我的术语 - 这是我经常与同事讨论的事情：）