The Kollected Kode Vicious

Kode Vicious - @kode_vicious

  下载本文的PDF版本 PDF

Kode Vicious

每朵乌云都镶有银边

缓存为王。如果你的缓存被削减,你将会感受到它的影响。

亲爱的 KV,

在过去的八周里,我的团队和我一直在调试一个应用程序性能问题,这个问题出现在我们迁移到云服务提供商的系统中。现在,为了庆祝,我们喝了几杯,并想告诉你这个故事,看看你是否有什么建议。

2016年,我们的管理层决定——为了省钱——我们将把我们所有的服务从我们小型办公室数据中心的两个机架中的自托管服务器迁移到云端,以便我们可以利用大多数云服务提供商提供的弹性定价。我们的系统使用相当通用的、现成的开源组件,包括 Postgres 和 Memcached,为我们的 Web 服务提供后端存储。

在过去的两年里,我们在系统性能调优方面积累了相当多的专业知识,所以我们认为我们很了解当我们把服务迁移到云端时我们需要什么。但我们发现的情况恰恰相反。

我们的第一个问题是查询响应时间非常不稳定。当我们把系统迁移到云服务后,数据库长查询的长尾开始增长,但每次我们去寻找根本原因时,问题都会消失。我们通常用来诊断我们在裸机上发现的问题的工具也给出了比预期更不一致的结果。最终,一些系统无法弹性分配,而必须静态分配,这样服务才能以一致的方式运行。管理层期望的节省从未实现。也许唯一的好处是我们不再需要维护我们自己的部署工具,因为部署由云服务提供商处理。

当我们啜饮着饮品时,我们想知道,这真的是一个常见问题吗,或者我们是否可以做些什么来使这次迁移不那么痛苦?

美梦泡汤

 

亲爱的 Rained,

显然,你们的管理层从未听说过“一分钱一分货”这句话。或者他们听说了,但没有意识到这句话也适用于他们。云计算的节省是以牺牲对系统的控制为代价的,这最好地概括在流行的书呆子贴纸上,上面写着:“云只是别人的电脑。”

过去两年里你构建的所有工具之所以有效,仅仅是因为它们直接了解系统组件,一直到硬件层面,或者至少尽可能接近硬件层面。一旦你将系统迁移到云端,你的应用程序就与其他竞争系统共享资源,如果你利用弹性定价,那么你的机器甚至可能在云服务提供商认为有必要之前都不会运行。请求延迟取决于立即获得资源来响应传入请求的可用性。这些资源包括 CPU 周期、内存中的数据、CPU 缓存中的数据和存储上的数据。在传统服务器中,所有这些资源都由你的操作系统在运行在操作系统之上的程序的指示下控制;但在云端,还有另一层,虚拟机,这在堆栈中增加了一个额外的“乌龟”,即使一直都是“乌龟叠罗汉”,这个额外的“乌龟”也将成为资源变化的原因。这就是你在将系统迁移到云端后看到不一致结果的原因之一。

让我们暂时只考虑 CPU 缓存的使用。现代 CPU 通过拥有大型、高效管理的 L1、L2 以及有时是 L3 缓存,获得了相当多的整体性能。CPU 缓存在所有程序之间共享,但在具有多个租户的虚拟化系统中,任何一个程序(例如你的数据库或 Memcached 服务器)可用的缓存量会随着每个租户的增加而线性减少。如果你在原来的托管中心有一个强大的服务器,你肯定从那些 CPU 中的大缓存中获得了性能提升。在云服务提供商中运行的同一台服务器将为你的程序提供大大减少的缓存空间。

由于缓存减少,快速内存中保留的东西也减少了,这意味着你的程序现在需要访问常规 RAM,而常规 RAM 通常比缓存慢得多。这些对内存的访问现在正在与其他也被压缩缓存的租户竞争。因此,尽管实例运行的真实服务器可能比你原来的硬件大得多——可能拥有近 TB 的 RAM——但每个租户在相同内存大小的虚拟实例中获得的性能远不如在具有相同内存量的真实服务器中获得的性能。

让我们用实际数字来想象一下。如果你的团队拥有一台现代双处理器服务器,配备 128 GB 内存,那么每个处理器将有 16 MB(不是 GB)的 L2 缓存。如果该服务器正在运行操作系统、数据库和 Memcached,那么这三个程序共享这 16 MB。使用同一台服务器并将内存增加到 512 GB,然后有四个租户,这意味着可用的缓存空间现在已缩减到原来的四分之一——每个租户现在只获得 4 MB 的 L2 缓存,并且必须与另外三个租户竞争之前拥有的所有相同资源。在现代计算中,缓存为王,如果你的缓存被削减,你将会感受到它的影响,就像你在尝试解决性能问题时所做的那样。

大多数云服务提供商都提供非弹性和弹性系统,但在云服务中始终保持服务器可用比在传统的托管设施中托管服务器更昂贵。这是为什么呢?这是因为云服务提供商的规模经济只有在每个人都参与游戏并允许云服务提供商决定如何消耗资源时才有效。

一些提供商现在有一种叫做金属即服务 (Metal-as-a-Service) 的东西,我真的认为这应该意味着一支 80 年代的金属乐队出现在你的办公室,演奏一场演出,砸碎家具,并在地毯上撒尿,但遗憾的是,这只是云服务提供商最终承认云计算并不是所有应用程序的正确答案的方式。对于需要确定性性能保证才能良好运行的系统,你真的必须认真考虑基于云的系统是否是正确的答案,因为提供确定性保证需要对环境中的变量进行相当多的控制。云系统不是为了给你控制权;而是为了让系统所有者拥有控制权。

KV

 

相关文章

云卡尺
Kode Vicious
命名下一代,并记住云只是别人的电脑
https://queue.org.cn/detail.cfm?id=2993454

可扩展性的 20 个障碍
Sean Hull
注意这些可能阻止 Web 应用程序扩展的陷阱。
https://queue.org.cn/detail.cfm?id=2512489

数据中心网络的导览
Dennis Abts, Bob Felderman
良好的用户体验取决于数据中心网络内可预测的性能。
https://queue.org.cn/detail.cfm?id=2208919

Kode Vicious,凡人称之为 George V. Neville-Neil,以网络和操作系统代码为乐并从中获利。他还教授与编程相关的各种主题的课程。他的兴趣领域是代码探险、操作系统和重写你的糟糕代码(好吧,也许不是最后一个)。他获得了马萨诸塞州波士顿东北大学的计算机科学学士学位,并且是 、Usenix 协会和 IEEE 的成员。Neville-Neil 是与 Marshall Kirk McKusick 和 Robert N. M. Watson 合著的《FreeBSD 操作系统设计与实现》(第二版)的作者之一。他是一位狂热的自行车爱好者和旅行者,目前居住在纽约市。

版权 © 2018 由所有者/作者持有。出版权已授权给 。

acmqueue

最初发表于 Queue 第 16 卷,第 2 期
数字图书馆 中评论本文





更多相关文章

Marc Brooker, Ankush Desai - AWS 的系统正确性实践
构建可靠和安全的软件需要一系列方法来推理系统正确性。除了行业标准测试方法(如单元测试和集成测试)外,AWS 还采用了模型检查、模糊测试、基于属性的测试、故障注入测试、确定性模拟、基于事件的模拟以及执行跟踪的运行时验证。形式化方法一直是开发过程的重要组成部分——也许最重要的是,形式化规范作为测试预言机,为 AWS 的许多测试实践提供了正确的答案。正确性测试和形式化方法仍然是 AWS 的关键投资领域,并且由于在这些领域已经看到的出色回报而加速发展。


Achilles Benetopoulos - 数据中心计算机的中间表示
我们已经到了分布式计算无处不在的地步。内存中的应用程序数据大小正在超过单台机器的容量,因此需要将其分区到集群中;在线服务具有高可用性要求,这只能通过将系统部署为多个冗余组件的集合来满足;高持久性要求只能通过数据复制来满足,有时甚至跨越广阔的地理距离。


David R. Morrison - 模拟:分布式系统中未被充分利用的工具
模拟在人工智能系统的出现中发挥着巨大的作用:我们需要一种高效、快速且经济高效的方法来训练人工智能代理在我们基础设施中运行,而模拟绝对提供了这种能力。


Matt Fata, Philippe-Joseph Arida, Patrick Hahn, Betsy Beyer - 从企业到云端:谷歌的虚拟桌面
超过四分之一的 Google 员工使用内部、数据中心托管的虚拟桌面。这种本地部署产品位于公司网络中,允许用户从世界任何地方远程开发代码、访问内部资源和使用 GUI 工具。在其最显着的特性中,虚拟桌面实例可以根据手头的任务调整大小,具有持久的用户存储,并且可以在公司数据中心之间移动以跟随出差的 Google 员工。直到最近,我们的虚拟桌面都托管在使用名为 Ganeti 的自制开源虚拟集群管理系统的 Google 公司网络上的商用硬件上。今天,这项庞大且对 Google 至关重要的工作负载在 GCP (Google Compute Platform) 上运行。





© 保留所有权利。

© . All rights reserved.