独家揭秘！阿里大规模数据中心的性能分析

阿里妹导读：数据中心已成为支撑大规模互联网服务的标准基础设施。随着数据中心的规模愈来愈大，数据中内心每一次软件（如 JVM）或硬件（如 CPU）的升级改造都会带来高昂的成本。合理的性能分析有助于数据中心的优化升级和成本节约，而错误的分析可能误导决策、甚至形成巨大的成本损耗。

本文整理自阿里巴巴高级技术专家郭健美（花名：希伯）在Java相关行业会议的分享，主要介绍阿里大规模数据中心性能监控与分析的挑战与实践，但愿对你有所启发。

做者简介：郭健美（花名：希伯），阿里巴巴高级技术专家，目前主要从事数据中心的性能分析和软硬件结合的性能优化。CCF 系统软件专委和软件工程专委的委员。

你们好，很高兴有机会与 Java 社区的开发者交流。个人研究领域在软件工程，主要集中在系统配置和性能方面。软件工程一个比较常见的活动是找 bug，固然找 bug 很重要，但后来也发现，即使 bug-free 的程序也会被人配置错，因此就衍生出了软件配置问题。

不少软件须要配置化，好比 Java 程序或 JVM 启动时能够配置不少参数。经过配置，一套软件能够灵活地提供各类定制化的功能，同时，这些配置也会对软件总体性能产生不一样的影响。固然这些还在软件配置方面，来了阿里之后，我有机会把这方面工做扩展到了硬件，会更多地结合硬件好比 CPU，来看系统的配置变动和升级改造对性能、可靠性以及业务上线效果的影响。今天主要谈谈我在这方面的一点工做。

阿里最有表明性的事件是“双 11”。这里仍是用的17年的数据，左上角是双十一的销售额，17年大概是 253 亿美金，比美国同期 Thanksgiving、Black Friday、Cyber Monday 加起来的销售额还要多。

固然这是从业务层面去看数据，技术同窗会比较关注右边的数据，17年双十一的交易峰值达到 32.5 万笔/秒、支付峰值达到 25.6 万笔/秒。对于企业来讲，这么高的峰值性能意味着什么？意味着成本！咱们之因此关注性能，就是但愿经过持续的技术创新，不断地提升性能、同时节省成本。

双十一零点的峰值性能不是一个简单的数字，其背后须要一个大规模数据中心来支撑。 简单来讲，阿里的基础架构的上层是各类各样的应用，好比淘宝、天猫、菜鸟、钉钉，还有云计算和支付宝等，这也是阿里的一个特点，即具备丰富的业务场景。

底层是上百万台机器相连的大规模数据中心，这些机器的硬件架构不一样、分布地点也不一样，甚至分布在世界各地。中间这部分咱们称之为中台，最贴近上层应用的是数据库、存储、中间件以及计算平台，而后是资源调度、集群管理和容器，再下面是系统软件，包括操做系统、JVM 和虚拟化等。

中台这部分的产品是衔接社区与企业的纽带。这两年阿里开源了不少产品，好比 Dubbo、PouchContainer 等，能够看出阿里很是重视开源社区，也很是重视跟开发者对话。如今不少人都在讲开源社区和生态，外面也有各类各样的论坛，可是像今天这样与开发者直接对话的活动并非那么多，而推进社区发展最终仍是要依赖开发者。

这样大规模的基础架构服务于整个阿里经济体。从业务层面，咱们能够看到 253 亿美金的销售额、32.5 万笔交易/秒这样的指标。然而，这些业务指标如何分解下来、落到基础架构的各个部分就很是复杂了。好比，咱们在作 Java 中间件或 JVM 开发时，都会作性能评估。

大部分技术团队开发产品后都会有个性能提高指标，好比下降了 20% 的 CPU 利用率，然而这些单个产品的性能提高放到整个交易链路、整个数据中内心面，占比多少？对数据中心总体性能提高贡献多少？这个问题很复杂，涉及面很广，包括复杂关联的软件架构和各类异构的硬件。后面会提到咱们在这方面的一些思考和工做。

阿里的电商应用主要是用 Java 开发的，咱们也开发了本身的 AJDK，这部分对 OpenJDK 作了不少定制化开发，包括：融入更多新技术、根据业务须要及时加入一些 patches、以及提供更好的 troubleshooting 服务和工具。

你们也知道，18年阿里入选并连任了 JCP EC(Java Community Process - Executive Committee) 职位，有效期两年，这对整个 Java 开发者社区、尤为是国内的 Java 生态都是一件大事。可是，不是每一个人都了解这件事的影响。记得以前碰到一位同仁，提到 JCP EC 对阿里这种大业务量的公司是有帮助，对小公司就没意义了。

其实不是这样的，参选 JCP EC 的时候，大公司、小公司以及一些社区开发者都有投票资格，小公司或开发者有一票，大公司也只有一票，地位是同样的。不少国外的小公司更愿意参与到社区活动，为何？

举个简单例子，因为业务须要，你在 JVM 8 上作了一个特性，费了很大的力气开发调试完成、业务上线成功，结果社区推荐升级到 JVM11 上，这时你可能又须要把该特性在 JVM 11 上从新开发调试一遍，可能还要多踩一些新的坑，这显然增长了开发代价、拉长了上线周期。但若是你能影响社区标准的制定呢？你能够提出将该特性融入社区下一个发布版本，有机会使得你的开发工做成为社区标准，也能够借助社区力量完善该特性，这样既提升了技术影响力也减小了开发成本，仍是颇有意义的。

过去咱们作性能分析主要依赖小规模的基准测试。好比，咱们开发了一个 JVM 新特性， 模拟电商的场景，你们可能都会去跑 SPECjbb2015 的基准测试。再好比，测试一个新型硬件，须要比较 SPEC 或 Linpack 的基准测试指标。

这些基准测试有必要性，由于咱们须要一个简单、可复现的方式来衡量性能。但基准测试也有局限性，由于每一次基准测试都有其限定的运行环境和软硬件配置，这些配置设定对性能的影响可能很大，同时这些软硬件配置是否符合企业需求、是否具备表明性，都是须要考虑的问题。

阿里的数据中内心有上万种不一样的业务应用，也有上百万台分布在世界各地的不一样服务器。当咱们考虑在数据中内心升级改造软件或硬件时，一个关键问题是小规模基准测试的效果是否能扩展到数据中内心复杂的线上生产环境？

举个例子，咱们开发了 JVM 的一个新特性，在 SPECjbb2015 的基准测试中看到了不错的性能收益，但到线上生产环境灰度测试的时候，发现该特性能够提高一个 Java 应用的性能、但会下降另外一个 Java 应用的性能。同时，咱们也可能发现即使对同一个 Java 应用，在不一样硬件上获得的性能结果大不相同。这些状况广泛存在，但咱们不可能针对每一个应用、每种硬件都跑一遍测试，于是须要一个系统化方法来估计该特性对各类应用和硬件的总体性能影响。

对数据中心来讲，评估每一个软件或硬件升级的总体性能影响很是重要。好比，“双11”的销售额和交易峰值，业务层面可能主要关心这两个指标，那么这两个指标翻一倍的时候咱们须要买多少台新机器？须要多买一倍的机器么？这是衡量技术能力提高的一个手段，也是体现“新技术”对“新商业”影响的一个途径。咱们提出了不少技术创新手段，也发现了不少性能提高的机会，但须要从业务上也能看出来。

为了解决上面提到的问题，咱们开发了 SPEED 平台。首先是估计当前线上发生了什么，即 Estimation，经过全域监控采集数据，再进行数据分析，发现可能的优化点。好比，某些硬件总体表现比较差，能够考虑替换。

而后，咱们会针对软件或硬件的升级改造作线上评估，即 Evaluation。好比，硬件厂商推出了一个新硬件，他们本身确定会作一堆评测，获得一组比较好的性能数据，但刚才也提到了，这些评测和数据都是在特定场景下跑出来的，这些场景是否适合用户的特定需求？

没有直接的答案。一般，用户也不会让硬件厂商到其业务环境里去跑评测。这时候就须要用户本身拿这个新硬件作灰度测试。固然灰度规模越大评测越准确，但线上环境都直接关联业务，为了下降风险，实际中一般都是从几十台甚至几台、到上百台、上千台的逐步灰度。SPEED 平台要解决的一个问题就是即使在灰度规模很小时也能作一个较好的估计，这会节约很是多的成本。

随着灰度规模增大，平台会不断提升性能分析质量，进而辅助用户决策，即 Decision。这里的决策不光是判断要不要升级新硬件或新版软件，并且须要对软硬件全栈的性能有一个很好的理解，明白什么样的软硬件架构更适合目标应用场景，这样能够考虑软硬件优化定制的方向。

好比，Intel 的 CPU 从 Broadwell 到 Skylake，其架构改动很大，但这个改动的直接效果是什么？Intel 只能从基准测试中给答案，但用户可能根据本身的应用场景给出本身的答案，从而提出定制化需求，这对成本有很大影响。

最后是 Validation，就是一般规模化上线后的效果来验证上述方法是否合理，同时改进方法和平台。

数据中内心软硬件升级的性能分析须要一个全局的性能指标，但目前尚未统一的标准。Google 今年在 ASPLOS 上发表了一篇论文，提出了一个叫 WSMeter 的性能指标，主要是基于 CPI 来衡量性能。

在 SPEED 平台里，咱们也提出了一个全局性能指标，叫资源使用效率 RUE。基本思想很简单，就是衡量每一个单位 Work Done 所消耗的资源。这里的 Work Done 能够是电商里完成的一个 Query，也能够是大数据处理里的一个 Task。而资源主要涵盖四大类：CPU、内存、存储和网络。一般咱们会主要关注 CPU 或内存，由于目前这两部分消费了服务器大部分的成本。

RUE 的思路提供了一个多角度全面衡量性能的方法。举个例子，业务方反映某台机器上应用的 response time 升高了，这时登陆到机器上也看到 load 和 CPU 利用率都升高了。这时候你可能开始紧张了，担忧出了一个故障，并且极可能是因为刚刚上线的一个新特性形成的。

然而，这时候应该去看下 QPS 指标，若是 QPS 也升高了，那么也许是合理的，由于使用更多资源完成了更多的工做，并且这个资源使用效率的提高可能就是由新特性带来的。因此，性能须要多角度全面地衡量，不然可能会形成不合理的评价，错失真正的性能优化机会。

下面具体讲几个数据中心性能分析的挑战，基本上是线上碰到过的具体问题，但愿能引发你们的一些思考。

首先是性能指标。可能不少人都会说性能指标我天天都在用，这有什么好说的。其实，真正理解性能指标以及系统性能自己并非那么容易。举个例子，在数据中内心最经常使用的一个性能指标是 CPU 利用率，给定一个场景，数据中内心每台机器平均 CPU 利用率是 50%，假定应用需求量不会再增加、而且软件之间也不会互相干扰，那么是否能够把数据中心的现有机器数量减半呢？

这样，理想状况下 CPU 利用率达到 100% 就能够充分利用资源了，是否能够这样简单地理解 CPU 利用率和数据中心的性能呢？确定不行。就像刚才说的，数据中心除了 CPU，还有内存、存储和网络资源，机器数量减半可能不少应用都跑不起来了。

再举个例子，某个技术团队升级了其负责的软件版本之后，经过线上测试看到平均 CPU 利用率降低了 10%，于是声明性能提高了 10%。这个声明没有错，但咱们更关心性能提高之后是否能节省成本，好比性能提高了 10%，是否能够把该应用涉及的 10% 的机器关掉？这时候性能就不该该只看 CPU 利用率，而应该再看看对吞吐量的影响。

因此，系统性能和各类性能指标，可能你们都熟悉也都在用，但还须要更全面地去理解。

刚才提到 SPEED 的 Estimation 会收集线上性能数据，但是收集到的数据必定对吗？这里讲一个 Hyper-Threading 超线程的例子，可能对硬件了解的同窗会比较熟悉。超线程是 Intel 的一个技术，好比咱们的笔记本，通常如今都是双核的，也就是两个 hardware cores，若是支持超线程并打开之后，一个 hardware core 就会变成两个 hardware threads，即一台双核的机器会有四个逻辑 CPU。

来看最上面一张图，这里有两个物理核，没有打开超线程，两边 CPU 资源都用满了，因此从任务管理器报出的整台机器平均 CPU 利用率是 100%。左下角的图也是两个物理核，打开了超线程，每一个物理核上有一个 hardware thread 被用满了，整台机器平均 CPU 利用率是 50%。

再看右下角的图，也是两个物理核，也打开了超线程，有一个物理核的两个hardware threads 都被用满了，整台机器平均 CPU 利用率也是 50%。左下角和右下角的 CPU 使用状况彻底不一样，可是若是咱们只是采集整机平均 CPU 利用率，看到的数据是同样的！

因此，作性能数据分析时，不要只是想着数据处理和计算，还应该注意这些数据是怎么采集的，不然可能会获得一些误导性的结果。

数据中内心的硬件异构性是性能分析的一大挑战，也是性能优化的一个方向。好比这里左边的 Broadwell 架构，是 Intel 过去几年服务器 CPU 的主流架构，近几年在推右边的 Skylake 架构，包含最新的 Cascade Lake CPU。Intel 在这两个架构上作了很大的改动，好比，Broadwell 下访问内存仍是保持多年的环状方式，而到了 Skylake 改成网格状方式。

再好比，L2 Cache 到了Skylake 上扩大了四倍，一般来讲这能够提升 L2 Cache 的命中率，可是 cache 越大也不表明性能就必定好，由于维护 cache coherence 会带来额外的开销。这些改动有利有弊，但咱们须要衡量利和弊对总体性能的影响，同时结合成原本考虑是否须要将数据中心的服务器都升级到 Skylake。

了解硬件的差别仍是颇有必要的，由于这些差别可能影响全部在其上运行的应用，而且成为硬件优化定制的方向。

现代互联网服务的软件架构很是复杂，好比阿里的电商体系架构，而复杂的软件架构也是性能分析的一个主要挑战。举个简单的例子，图中右边是优惠券应用，左上角是大促主会场应用，左下角是购物车应用，这三个都是电商里常见的业务场景。从 Java 开发的角度，每一个业务场景都是一个 application。电商客户既能够从大促主会场选择优惠券，也能够从购物车里选择优惠券，这是用户使用习惯的不一样。

从软件架构角度看，大促主会场和购物车两个应用就造成了优惠券应用的两个入口，入口不一样对于优惠券应用自己的调用路径不一样，性能影响也就不一样。

因此，在分析优惠券应用的总体性能时须要考虑其在电商业务里的各类错综复杂的架构关联和调用路径。像这种复杂多样的业务场景和调用路径是很难在基准测试中彻底复现的，这也是为何咱们须要作线上性能评估。

这是数据分析里著名的辛普森悖论，在社会学和医学领域有不少常见案例，咱们在数据中心的性能分析里也发现了。这是线上真实的案例，具体是什么 App 咱们不用追究。

假设还用前面的例子，好比 App 就是优惠券应用，在大促的时候上线了一个新特性 S，灰度测试的机器占比为 1%，那么根据 RUE 指标，该特性能够提高性能 8%，挺不错的结果。可是若是优惠券应用有三个不一样的分组，分组假设就是关联刚才提到的不一样入口应用，那么从每一个分组看，该特性都下降了应用的性能。

一样一组数据、一样的性能评估指标，经过总体汇集分析获得的结果与经过各部分单独分析获得的结果正好相反，这就是辛普森悖论。既然是悖论，说明有时候应该看整体评估结果，有时间应该看部分评估结果。在这个例子里面，咱们选择看部分评估、也就是分组上的评估结果，因此看起来这个新特性形成了性能降低，应该继续修改并优化性能。

因此，数据中内心的性能分析还要预防各类可能的数据分析陷阱，不然可能会严重误导决策。

最后，还有几分钟，简单提一下性能分析师的要求。这里一般的要求包括数学、统计方面的，也有计算机科学、编程方面的，固然还有更重要的、也须要长期积累的领域知识这一块。这里的领域知识包括对软件、硬件以及全栈性能的理解。

其实，我以为每一个开发者均可以思考一下，咱们不光要作功能开发，还要考虑所开发功能的性能影响，尤为是对数据中心的总体性能影响。好比，JVM 的 GC 开发，社区里比较关心 GC 暂停时间，但这个指标与 Java 应用的 response time 以及所消耗的 CPU 资源是什么关系，咱们也能够有所考虑。

---

本文做者：郭健美

阅读原文

本文来自云栖社区合做伙伴“ 阿里技术”，如需转载请联系原做者。