它正在使用的一些库正在对文件系统级别进行锁定.不幸的是,它没有正常工作,如果有一些并发使用的库会崩溃并抛出错误.我们也无法切换这个库.要实现并发,哪一个更好？在一台功能强大的机器中运行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台小型机器,由于操作系统或其他因素,整体性能可能会更慢？无论如何,我对此没有任何经验.当然我可以试试这个,但最后,因为它不是理想的环境(有很多因素),所以结果不会是权威的.我一直在寻找那些知道两种情况如何在低级别工作的人的答案,并且可以论证哪种环境能够更快地完成任务.
解决方法
那就是说,让我告诉你在对这种情况进行分析时我会考虑什么.
>码头工人的开销应该是绝对最小的.工具“docker”本身没有做任何事情 – 它只是使用常规的Linux内核功能为您的应用程序创建一个独立的环境.
>操作系统启动后,会消耗一些内存,为真.但操作系统本身的CPU消耗应该可以忽略不计(即使对于非常小的实例).既然你提到你没有任何内存问题,似乎我们可以假设你的同事提到的这个“操作系统开销”也可能是微不足道的.
>如果您认为路径“很多非常小的实例”,您还可以考虑使用最近发布的t2.nano实例类型.您需要测试它是否有足够的资源来实际运行您的应用程序.
>如果您认为路由是“一个非常大的实例”,您还应该考虑c4.8xl实例.这应该会给你比c3.8xl更多的CPU功率.
>成本分析(价格在美国东部1)：
> 1x c3.8xlarge：1.68 $/ h
> 1x c4.8xlarge：1.675 $/ h(与c3.8xl大致相同)
> 100x t2.micro：1.30 $/ h(即100x 0.013 $/ h = 1.30 $/ h)
> 100x t2.nano：0.65 $/ h. (获胜者)(即100x 0.0065 $/ h = 0.65 $/ h)
>现在让我们分析一下每次设置的资源量.我只关注CPU并忽略内存,因为你提到你的应用程序不是内存饥饿：
> 1x c3.8xlarge：32 vCPU
> 1x c4.8xlarge：36个vCPU(每个通常具有比c3.8xl更好的性能; c4的芯片是由英特尔为EC2专门设计的)(获胜者)
> 100x t2.micro：100x 10％的vCPU~ =“10 vCPU”聚合
> 100x t2.nano：100x 5％的vCPU~ =“5 vCPU”聚合
>最后,让我们分析每个资源的成本
> 1x c3.8xlarge：1.68 $/ h / 32 vCPU = 0.0525 $/(vCPU-h)
> 1x c4.8xlarge：0.0465 $/(vCPU-h)(获胜者)
> 100x t2.micro：0.13 $/(vCPU-h)
> 100x t2.nano：0.13 $/(vCPU-h)
如您所见,较大的实例通常提供更高的计算密度,通常更便宜.
您还应该考虑这样一个事实,即T2实例是“可突发的”,因为它们可以在一段时间内超出其基线性能(如上所述的10％和5％),具体取决于它们具有多少“CPU信用”.但是,您应该知道,虽然它们从一些信用余额开始,但它通常足以启动操作系统而不是更多(如果您不将CPU推到基线以上,那么随着时间的推移会产生更多的CPU信用额度,但似乎不会出现这种情况,因为我们正在优化性能……).正如我们所看到的,“每个资源的成本”几乎是8xl实例的3倍,所以你得到的这个短暂的爆发可能不会改变这个粗略的估计.
您可能还需要考虑网络利用率.应用程序网络密集吗？在延迟要求,带宽要求或每秒数据包数量？
>较小的实例可用的网络性能较低,较大的实例具有更多.但是每个较小实例的网络将由一个应用程序使用,而较大实例的强大网络将在所有容器之间共享. 8xl实例配有10Gbps网卡.与此相比,t2实例的网络性能非常低.
现在,弹性呢？这些工作对时间敏感度如何？什么是“没有及时完成它们的成本”？您可能还想考虑一些失败模式：
>如果“单个实例死亡”会发生什么？在1x c3.8xl或1x c4.8xl的情况下,你的整个车队都会倒塌,你的工人就会停下来.他们能够“恢复”吗？他们需要“重启”他们的工作吗？在“很多小事件”的情况下,“单一实例死亡”的影响可能会小得多.
为了减少“单个实例死亡”对您的工作负载的影响,并且仍然从更高密度的计算(即大型c3或c4实例)中获得一些好处,您可以考虑其他选项,例如：2x c4.4xl或4x c4.2xl,依此类推.请注意,c4.8xl的成本是c4.4xl的两倍,但它包含的vCPU数量是其两倍多.所以上面的分析不是“线性的”,你需要重新计算一些成本.
假设您对实例“失败”没问题并且您的应用程序可以某种方式处理它 – 另一个有趣的要点是使用Spot实例.使用竞价型实例,您可以为价格命名.如果“市场价格”(由报价 – 需求调节)低于您的报价,您将获得该实例并仅支付“市场价格”.如果价格波动高于您的出价,那么您的实例将被终止.与On Demand相比,看到高达90％的折扣并不罕见.截至目前,一个AZ的c3.8xl约为0.28 $/ h(比按需减少83％),一个AZ的c4.8xl大致相同(也减少了83％).现货定价不适用于t2实例.
您还可以考虑使用Spot Block,您可以在其中说明您希望运行实例的小时数,您通常需要支付30％ – 比按需减少45％,并且在此期间不会出现“超出限制”的风险你指定了.在此期间之后,您的实例将被终止.
最后,我会尝试调整我的服务器大小,以便它们几乎需要“完整的小时”(但不超过该数量)(除非我需要尽快完成执行).也就是说,拥有一个能够在50分钟内完成工作的小型车队要好于能够在10分钟内完成工作的大型车队.原因是：您按小时,小时开始付款.此外,通常情况下,拥有一个能够在50分钟内完成工作的大型车队比需要1小时05分钟的小型车队要好得多 – 再次,因为您按小时付款,在小时开始时.
最后,你提到你正在寻找“最佳表现”.你到底是什么意思？您的关键绩效指标是什么？您想优化以减少总共花费的时间吗？也许减少“每单位”/“每份工作”的时间量？你想减少你的成本吗？您是否想要更加“节能”并减少碳足迹？或者可以优化所需的维护量？或者专注于简化以减少其他同事在能够维护解决方案之前需要知识不足的上升期限？
也许是上面许多绩效指标的组合？他们将如何结合？总是有一个权衡…
如你所见,没有一个明显的赢家.至少没有关于您的应用程序和优化目标的更具体信息.这就是为什么大多数时候任何类型的性能优化的最佳选择都是真正的测试.测试通常也很便宜：它可能需要几个小时的工作来设置您的环境,然后可能不到2美元/小时的测试.
所以,这应该给你足够的信息来开始你的调查.
快乐的测试！
