如何使用火焰图来分析服务器负载
《如何使用火焰图来分析服务器负载》要点:
在 Lucid,我们使用面向服务的架构来建设我们的系统.其中字体服务(font service)就是其中之一,它负责根据字体族名称和 unicode 编码范围来提供相应的字体服务,同时也对用户上传的字体进行校验和检查.在生产环境中,该服务的负载一直很高,这一点超出我们的预期(使用或等待 CPU 的平均线程数).特别从去年开始,我们注意到字体服务的负载高的惊人,特别是在晚上这样的流量低峰时期. 幸运的是最终我们找到了根本原因,并通过改进大大提高了服务的整体性能和稳定性.通过下面的内容,您将了解到我们是如何做到的. 图1: 字体服务在变更前后服务器平均负载对比 通过火焰图来调试和发现问题我们从 Netflix 找到了一个非常棒的火焰图工具,并部署到生产环境. 此工具可以将多个不同调试分析工具的数据组合在一起并生成火焰图,以可视化的方式展示服务器和 JVM 的资源使用情况. 如下图所示,每个矩形表示一个栈帧,同时矩形的宽度代表了资源(比如 CPU 时间)的使用情况,Y 轴表示调用栈.通过识别那些宽的矩形块,就能快速缩小问题范围.在调试和排查字体服务时,它极大地帮助了我们. 图2: 高负载时字体服务中一台服务器的火焰图 在高负载状态下,我们对字体服务收集数据并生成了几个火焰图.下图是其中之一,并且特别展示了 JVM 相关栈的部分.可以分析得出,大部分时间都花在了 图3: JVM 相关栈活动的局部火焰图 找到慢的原因首先多啰嗦几句这个字体服务的一些背景情况.我们将所有字体相关数据存储在 Amazon S3 中,具体来说是将每个字体的每个 unicode 范围分别存为一个 功能非常简单,并没有什么明显的密集型计算.但是对于出现的高负载问题,火焰图帮助我们识别出了问题所在—— 但是为什么会产生这么多编码和压缩的消耗?记得前面提到晚上时间的负载反而是最高的吗?我们的晚上(美国山区时间)正好是亚洲地区的白天,该地区很多用户都使用中文、日文或韩文等亚洲语言.会进行大量的 gzip 解压缩 → UTF-8解码 → XML 转义 → UTF-8编码 → gzip 压缩.相比于拉丁语系,单个 CJK 的 unicode 范围比拉丁语系的 unicode 范围大2个数量级(1MB:60KB).所以上述的转换过程都压到了 CPU 上,特别压缩和解压缩,以及 XML 转义这类操作. 如何改进?字体服务对请求的响应本质上只是 S3 上原始数据的集合.它确实需要执行一些重要的附加任务,如权限检查和从字体族中检索名称.但是,字体服务根本没必要挡在 S3 前面来代理那些字体数据!所以解决办法很简单,直接用包含 S3 object 的链接(就是那些字体数据)的列表作为响应返回,字体服务不再从 S3 下载并重新编码字体数据.所以从图1中可以看出负载几乎降低到可忽略的程度. 总结通过调试分析生产环境,我们能够找到并消除那些不必要的任务和工作,进而降低服务器负载.
参考链接[1] Brendan D. Gregg的个人网站 http://www.brendangregg.com 原文来自微信公众号:高可用架构 (编辑:广西网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |