如何使用火焰图来降低服务器负载

LucidChart 提供在线编辑流程图、网络拓扑图、ER 图、 UML 图以及脑图等多种图表服务，有超过 7 百万的用户，因其简单直观的交互体验和强大的多人协作功能，是可以替代 Visio 的最佳选择。

在 Lucid，我们使用面向服务的架构来建设我们的系统。其中字体服务（font service）就是其中之一，它负责根据字体族名称和 unicode 编码范围来提供相应的字体服务，同时也对用户上传的字体进行校验和检查。在生产环境中，该服务的负载一直很高，这一点超出我们的预期（使用或等待 CPU 的平均线程数）。特别从去年开始，我们注意到字体服务的负载高的惊人，特别是在晚上这样的流量低峰时期。

幸运的是最终我们找到了根本原因，并通过改进大大提高了服务的整体性能和稳定性。通过下面的内容，您将了解到我们是如何做到的。

图1: 字体服务在变更前后服务器平均负载对比

通过火焰图来调试和发现问题

如下图所示，每个矩形表示一个栈帧，同时矩形的宽度代表了资源（比如 CPU 时间）的使用情况，Y 轴表示调用栈。通过识别那些宽的矩形块，就能快速缩小问题范围。在调试和排查字体服务时，它极大地帮助了我们。

图2: 高负载时字体服务中一台服务器的火焰图

在高负载状态下，我们对字体服务收集数据并生成了几个火焰图。下图是其中之一，并且特别展示了 JVM 相关栈的部分。可以分析得出，大部分时间都花在了 libz.so 这一步（gzip 使用该库进行压缩/解压缩操作），剩下大部分时间都花在了 XML 转义和 UTF-8 编码上。

图3: JVM 相关栈活动的局部火焰图

找到慢的原因

S3 object。当其他服务请求为了获取字体族，一组 unicode 范围，或者是用户自定义字体时会向字体服务请求字体数据，接着字体服务将字体数据包裹在 XML 中返回。libz，XML 转义和 UTF-8编码都使用了大量的 CPU。

但是为什么会产生这么多编码和压缩的消耗？记得前面提到晚上时间的负载反而是最高的吗？我们的晚上（美国山区时间）正好是亚洲地区的白天，该地区很多用户都使用中文、日文或韩文等亚洲语言。会进行大量的 gzip 解压缩 → UTF-8解码 → XML 转义 → UTF-8编码 → gzip 压缩。相比于拉丁语系，单个 CJK 的 unicode 范围比拉丁语系的 unicode 范围大2个数量级（1MB：60KB）。所以上述的转换过程都压到了 CPU 上，特别压缩和解压缩，以及 XML 转义这类操作。

如何改进？

总结

1. 使用例如火焰图之类的分析工具（profiling tool）来帮助识别 CPU 高占用的操作。

2. 压缩/解压缩和各种编码/解码的操作都是昂贵的。

3. 如果客户端可以直接访问数据，那么相比代理（客户端去请求）数据，直接返回链接是最好的选择，可以显著提高整体性能。

参考链接

[1] Brendan D. Gregg的个人网站 http://www.brendangregg.com

[2] Flame graphs http://www.brendangregg.com/flamegraphs.html

[3] 白话火焰图 https://huoding.com/2016/08/18/531

[4] Java Flame graphs http://www.brendangregg.com/blog/2014-06-12/java-flame-graphs.html

[5] OpenRestry 关于火焰图在 Lua 中的使用 https://moonbingbing.gitbooks.io/openresty-best-practices/flame_graph.html

[6] 在 Netflix 中的应用 http://techblog.netflix.com/2015/07/java-in-flames.html

[7] 在 Netflix 中的应用 http://techblog.netflix.com/2016/04/saving-13-million-computational-minutes.html

推荐阅读

• 被忽视的位图数据库：Pilosa查询十亿级出租车搭乘数据案例

• 如何快速获得高并发编程经验？PCC性能挑战赛作品简介及源代码

• 如何构建日请求数十亿次高性能高可用广告系统：微博广告架构解密

• LinkedIn:如何利用大数据算法定位网站性能瓶颈(BOSS)

本文作者 Thayne McCombs，由魏佳翻译，转载请注明出处，技术原创及架构实践文章，欢迎通过公众号菜单「联系我们」进行投稿。

高可用架构

改变互联网的构建方式

长按二维码 关注「高可用架构」公众号