[论文阅读笔记]GOOGLE-WIDE PROFILING: A CONTINUOUS PROFILING INFRASTRUCTURE FOR DATA CENTERS
Motivation
Google-Wide Profiling (GWP)需要每天在几千个服务器上采集profiling数据，每天采集的数据压缩后也有几GB。这会带来以下挑战：
- 验证这些采集的数据的正确性非常challenging，因为负载始终在动态变化
- 控制采集数据带来的开销也非常重要，因为任何不必要的数据采集行为都会消耗价值几百万美元成本的资源。
- 使profiling数据能被轻松访问也非常challenging
采集到的这些海量数据可以帮助我们解答以下有关数据中心性能优化的一些问题：
- 哪些是最活跃的进程、routine、代码区？
- 不同版本的软件性能差异如何？
- 哪些锁被经常争夺？
- 哪些进程最占用内存？
- 一个特定的内存分配行为可以对一类特定应用有增益吗？
- 应用在不同平台下的CPI各是多少？
除此之外，我们还可以基于更高层次的数据推断出更加复杂的结论，例如：
Infrastructure
上图展示了整个GWP的组成，包括：
Collector
-
GWP在两个维度上进行profiling: 首先每次只是在一部分机器上进行采样，其次在每台机器上针对事件进行采样。event-level如果每时每刻在每个机器上都活跃地采集数据，则会消耗太多资源；相反地，如果event-level的采样率太低，那么profiles就会过于稀疏。因此，对于每种事件类型使用不同的采样率。对于每一种事件，GWP相应地选择了一个足够高的采样率来保证能够提供足够丰富的数据，同时减少由于在关键应用上做profile带来的distortion。
-
一个中心机的数据库管理所有的集群机器，GWP周期性地从这个数据库获取所有机器的一个list，并随机从中采样选取一些机器作为样本，然后激活这些机器的profiling，并取回结果。它可以顺序地依次取回每种结果，也可以并发地取回结果。
-
为了减少profile结果失真，collector会检测机器上是否出现故障。如果故障比例超过一定的阈值那么就会停止profiling
除此之外，还采用了以下措施来减少overhead：
- 使用benchmark来测试event-based profiling的overhead开销有多大，然后保守地选择最大的采样速率
- call stack信息在高负载的时候不会收集全部
- 采集数据都是raw format的。symbolization是在另外机器上面完成的
结果表面，因profiling带来的overhead可以忽略不计：只占不到0.01%，同时采集到的数据仍然是有意义的。
Profiles and profiling interfaces
GWP采集两类profile: whole-machine, per-process
- whole-machine: 捕捉物理机上发生的所有活动，包括用户应用、kernel、kernel模块、daemons等等
- 没有root权限的用户无法直接调用绝大部分whole-machine profiling system。因此我们在每台物理机上部署轻量级的daemons，使得remote users可以访问这些profiles。daemons同时可以作为gate keeper控制访问权限，限制sampling rate，采集系统变量等。
- per-process: 收集每个进程的profile信息是通过google-pertools来完成的
- 绝大部分应用都包含一个通用的库，使得可以profile进程数据，例如堆的分配情况、锁的冲突情况等等。这个通用库内置一个简单的HTTP服务器，连接了各种profiler，远程用户可以请求每个profiler的handler将数据发送过去。
Symbolization and binary storage
在采集完数据后，使用Google File System存储这些profiles。为了提供有价值的信息，必须把profiles和对应的源码关联起来。然而，为了节约网络带宽和磁盘空间，应用在部署到数据中心的时候往往不包含任何debug或符号信息，这使得建立关联非常困难。
此外，一些应用，例如基于Java的，是即时编译执行的，而它们的代码往往在线下找不到，因此无法被符号化。
现在实现方式是在一个中央存储中心存储所有的没有strip掉debug信息的binary。由于binary往往太大，对每天的profile的symbolization会非常费时，因此用MapReduce分布式处理symbolization任务以减少延迟。
Profile storage
将数据存储在dimensional database中，使用类似SQL的查询语句。考虑到大部分的查询都频繁出现，因此为了提高查询速度，采用了比较激进的cache策略以减少延迟。
User interfaces
待更新
Application-specific profiling
尽管默认的采样率已经足够高，可以确保高置信度，但是对于个别应用，GWP可能无法采集足够多的样本。增加整体的采样率虽然可以覆盖到这些应用，但是开销太大了，因为这些应用非常稀疏。
因此，本文给GWP设计了一个extension以支持application-specific profiling。application-specific profiling的机器池一般来说要比GWP的小很多，因此对于application-specific profiling的机器池，可以采用更高的采样率。
同样地，我们还可以把profiling的采用时间段限制到应用的运行周期里。
Reliability analysis
为了减少连续profile的开销，我们在时间和机器两个维度上做了sampling。sampling必然带来variation，因此我们需要了解sampling对profiling的质量的影响。但是这很难做到，因为数据中心的负载的行为常常变化。没有直接的方法来评估profiles的代表价值。因此，本文采用以下两种间接方式评估profiles的质量：
1. 分析profiles的稳定性
我们用熵来评估一个给定profile的variation。熵H可定义为：
其中\(n\)是profile里的条目总数，\(p(x_i)\)是profile里条目名称为\(x_i\)占据的数量比例
熵高意味着样本数量多, 且profile是flat的 (个人理解是指profile里采集了很多entry，且样本在各个entry上分布相对比较均匀) 。熵低意味着样本数量少，或者大部分样本集中在极少数的几个条目名里。
熵不能反应不同条目名之间的差异。例如：一个function profile有x%的名为foo的条目，和y%的名为bar的条目，另一个function profile有y%的名为foo的条目，和x%的名为bar的条目，这两个profile的熵是相等的。因此，为了反映出不同profile之间同一个条目名的差异，我们计算两个profile的top \(k\)个条目名的Manhattan distance:
\(X,Y\)分别代表两个profile。\(p_X(x_i)\)表示条目名为\(x_i\)在profile \(X\)里占据的数量比例。
daily application-level profiles的熵在不同时间点都很稳定，而且其始终在一个很窄的区间里。样本数量和profile的熵之间相关性很弱，表明一旦样本数量足够多，对熵的影响就不大。
上图分析了application’s function-level profile，上图(a)将该应用在所有物理机上的数据收集到了一起，反映不同时间点该profile的样本数量和熵的值; 上图(b)反映了该应用在每个物理机上采集的profile (对应于每个方点)的样本数量(x坐标)和熵(y坐标)。
从上图(a)可以发现熵非常稳定，上图(b)表明该应用在不同物理机上的profile的样本数量差异非常大。样本数量少的机器上的熵很小，但一旦某机器上样本数量超过一个阈值，熵就比较稳定了。
我们用Manhattan distance来反映不同profile之间在同样的entry name之间的差异度，距离小代表差异度小。
从上图的trend line可以发现，用下式能刻画出Manhattan distance和样本数量之间的关系:
\(N(X)\)代表一个profile里的样本数量，\(C\)是一个常量，因profile类型而异。
此外，我们还可以用其他profile推导得到新的metric，并评估这个derived metric的稳定性。例如，我们可以从HPM的profile推导出(derived) CPI。上图表明derived CPI在不同日期也表现稳定。
2. 用其他来源的性能数据和profile相关联，做交叉验证。
本文还用了其他数据来源的profile和GWP采集的profile做交叉验证。一个例子是数据中心的监控系统采集的utilization data，和GWP相比，其采集了数据中心里所有机器的数据，但粒度更粗(如overall GPU utilization)，其CPU utilization data，在core-seconds这个metric上，经过公式换算后和GWP的CPU cycles profile是match的
