Google数据中心性能分析

近年来,各大公司都在组建自己的数据中心,国内有百度、腾讯、华为、阿里、字节等,国外有亚马逊、谷歌、脸书、推特等。数据中心通过集中管理和运维,为用户提供廉价的云计算和云存储的资源。

在如此大规模的情况下,理解数据中心的性能特征就变得尤为重要,因为哪怕1%的性能提升也能带来巨大的经济效益。尽管有人称"The datacenter as a computer",但针对数据中心的性能分析仍较为困难。一方面,数据中心提供了许多集群层面的服务,例如k8s[1]、GFS[2]、BigTable[3]、MapReduce[4]、Borg[1]。另一方面数据中心应用非常丰富,例如视频、搜索、机器学习、邮件、广告等,但没有所谓的"Killer application",即对对性能影响非常明显的应用。这些应用对计算、存储、通信、网络的要求不尽相同,并且其行为与用户使用情况有密切关联。因此在如此复杂的情况下提升数据中心性能是一件非常困难的事情。

[1] Borg, Omega, and Kubernetes. Commun. ACM (May 2016)

[2] The Google file system. (SOSP '03).

[3] Bigtable: a distributed storage system for structured data. (OSDI '06).

[4] MapReduce: simplified data processing on large clusters. (OSDI'04).

下图总结了2010年以来和Google在数据中心性能分析方面相关的部分工作。这些工作大致可以分为三类,Profiling、Indicator和Solution。在Profiling层面,需要集群实时性能数据采样的支持,即2010年的GWP,和分析数据的方法论,即Intel在2014年提出的Top-Down方法。在Indicator层面,需要为集群性能优化提供方向。这里除了Top-Down方法提供的四类瓶颈,Google还提到同步多线程方面的参考。2016年的文章指出将前端、后端和多线程三个方面作为重点优化方向。在Solution层面,Google研发了AutoFDO和ASMDB工具提供编译驱动、反馈制导的解决方案。ASMDB负责存储函数、基本块、指令、性能数据、CFG图等方面的信息,AutoFDO负责实施编译优化。两者相互配合,改进前端阻塞的性能瓶颈,并提出代码预取指令的硬件优化方案。在后端,大量的加速器被开发出来,例如GZIP加速器[11]、XML加速器[9-10]、内存拷贝加速器[12-13],甚至有UCB的学生帮忙写了Protocol Buffer的加速器。这项工作浩大却工具完善,并且有条不紊的推进,相信后续还会有更多相关工作发表在高水平会议上。

微信截图_20201125153744.png

下面针对其中几篇文章进行简述。

[1] Google-Wide Profiling: A Continuous Profiling Infrastructure for Data Centers. MICRO 2010

[2] A Top-Down method for performance analysis and counters architecture. ISPASS 2014

[3] Profiling a Warehouse-Scale Computer. ISCA 2015

[4] Auto-FDO: Automatic feedback-directed optimization for warehouse-scale application. CGO 2016

[5] ASMDB: Understanding and Mitigating Front-End Stalls in Warehouse-Scale Computer. ISCA 2019

[6] Datacenter Tax Cuts: Improving WSC Efficiency Through Protocol Buffer Acceleration.

[7] Web search for a planet: The google cluster architecture. Micro, 2003.

[8] Memory hierarchy for web search. HPCA.2018

[9] A 1 cycle-per-byte XML parsing accelerator. In Field Programmable Gate Arrays, 2010.

[10] XML accelerator engine. In Workshop on High Performance XML Processing, 2004.

[11] FPGA implementation of GZIP compression and decompression for IDC services. (FPT), 2010.

[12] Cache-based memory copy hardware accelerator for multicore systems. IEEE Transactions on Computers, 2010.

[13] Row-Clone: Fast and Energy-efficient in-DRAM Bulk Data Copy and Initialization. MICRO 2013.

1. GWP

2010年,Google构建了数据中心性能分析的基础硬件,Google-Wide Profiling,简称GWP,相关工作发布在MICRO2010上。这篇文章主要介绍了GWP的构成、性能数据处理流程和用途举例。

GWP连续采集集群软硬件信息,为后续优化提供实际性能数据。GWP主要组件包括:收集器、符号链接器、数据库和Web服务器。

微信截图_20201125095454.png

GWP使用硬件计数器收集处理器的架构信息,使用编译器为应用程序打上符号信息。这两部分信息会同时传递给收集器,形成原始剖析信息。同时还会查询集群任务管理系统查询某机器上运行的是哪种应用。

随后需要用到符号链接器,负责将静态代码分析获得的符号链接到动态代码执行流中。

使用GFS存储的大量性能数据和MapReduce链接处理过的性能分析文件被存储到一个只读数据库当中,同时提供用户查询的Web服务器和供分析人员使用的接口。

用户可以查询:某应用在其子函数上的耗时、函数调用关系图、代码热度注释等信息,帮助定位具体代码优化位置。用户也可以将分析限制在指定的应用上并以更高的采集频率采集数据。

用途举例:云应用性能和代码优化、寻找最热共享代码、评价硬件特性、优化应用亲和力、数据中心性能监控、反馈制导的优化

2. Top-Down方法

2014年,Intel提出了一套分析处理器性能瓶颈指导代码优化的方法,名为Top-Down。该方法将处理器性能瓶颈分为四大类:推测执行错、指令退出、前端阻塞、后端阻塞。然后层层分解,直到抓取到关键性能瓶颈,进而对程序进行优化。Top-方法被诸多文献所采用,例如文献[1,2],以及第3节和第5节将要介绍的文章。也有自动化的工具完成top-down分析,例如[3]。

微信截图_20201125095549.png

[1] G. Ayers, J. H. Ahn, C. Kozyrakis and P. Ranganathan, "Memory Hierarchy for Web Search," 2018 IEEE International Symposium on High Performance Computer Architecture (HPCA), Vienna, 2018, pp. 643-656, doi: 10.1109/HPCA.2018.00061.

[2] T. Liu et al., "A Benchmarking Framework for Interactive 3D Applications in the Cloud," 2020 53rd Annual IEEE/ACM International Symposium on Microarchitecture (MICRO), Athens, Greece, 2020, pp. 881-894, doi: 10.1109/MICRO50266.2020.00076.

[3] https://github.com/andikleen/pmu-tools

3. Profiling A WSC

2016年,Google使用Top-Down的方法分析自己的数据中心,毕竟“The data center is the computer”[1]。文章有两个主要的产出。一是提出了Data Center Tax,即数据中心税,指数据中心中被多个业务共享的部分开销。下图中总结其中七类热点程序对集群的开销。

微信截图_20201125103457.png

二是使用Top-Down的方法,分析数据中心目前的几个主要瓶颈。除了此前的前端阻塞和后端阻塞,还提到多线程对资源利用率的影响。

改文章起到了承上启下的作用。一方面承接2010年的GWP,想使用集群性能数据做一些事情。另一方面,在分析的基础上提出了几点优化方向,为2019的ASMDB解决前端阻塞问题埋下了伏笔。

[1] David A Patterson. The data center is the computer. Communications of the ACM, 2008.

4. AutoFDO

同样是2016年,Google发表了AutoFDO,是Feedback-directed optimization的自动化版本。这篇文章偏编译,我没有完全看懂,主要的思路是通过程序运行的结果,指导编译优化。文章也主要分为两部分,分析性能数据和实施编译优化。有这相关的大牛可以帮忙解说一下就再好不过了。

5. ASMDB

2019年的ASMDB综合上述所有的技术和工具,来解决数据中心中前端阻塞的问题。数据中心软件栈较深,代码工作集大小在4-6MB,造成频繁的L1 Cache Miss率居高不下。这个工作主要集中在两个方面,一是使用代码预取,使用编译方法插入预取指令。二是使用细粒度的冷热代码分析,通过编译的方法将热代码集中到一个Cache行中,提高预取的效果。对memcmp函数的优化使得最终数据中心的性能提升了1-2%。

更多信息可以参看我的另一篇文章专门介绍ASMDB。
https://www.jianshu.com/p/033662549e24

你可能感兴趣的:(Google数据中心性能分析)