案例分享:在生产中持续使用Amazon CodeGuru Profiler进行程序优化

亚马逊云AI社区

image

本文由 Atlassian 高级软件工程师 Behrooz Nobakht、工程技术经理 Matthew Ponsford 以及高级软件工程师 Narayanaswamy Anandapadmanabhan 联手撰写。

全球范围内,有成千上万的团队正在使用 Atlassian 公司的 Jira 云性能团队所开发的 Jira 及 Trello 等工具。该团队致力于为用户创造出色的产品、实践与开放的工作成果。Jira 云性能团队是一个专项工作组,致力于让 Jira 与 Atlassian 团队能够更好地了解、监控并增强自有产品及服务的性能表现。

背景介绍

Atlasian 目前构建的产品有数百名开发人员负责进行开发,这些产品包括单体应用程序和微服务程序。当出现突发事件时,由于代码库中的代码变更很频繁,这样很难对问题进行快速根因诊断。

通过代码剖析可以显著加快根因诊断,代码剖析是识别应用程序中的运行时问题和延迟问题的有效技术。如果不采用代码剖析,通常需要自定义代码和临时延迟检测,这种方式容易出错而且会引起其他副作用。Atlassian 一直有工具用于剖析生产中的服务,例如使用 Linux perf)或async-profiler,虽然这些工具非常有价值,但他们的方法仍有一些限制:

  • 需要人员(或系统)的干预,才能在正确的时间捕获配置文件,这意味着经常错过一些暂时性问题
  • 临时剖析,无法提供要与之前比较的基线信息
  • 出于安全性和可靠性的考虑,在生产环境中运行这些工具的情况并不多

这些限制促使 Atlassian 研究持续剖析(Continuous profiling)。除了帮助诊断服务花费的 CPU 周期(或时间)外,他们还希望找到一种分析解决方案,提供火焰图等可视化效果,这些可视化效果对于后续问题诊断有很大的帮助,比如可以更快地通过调用路径理解复杂动态应用程序的调用关系,还可以用于帮助开发人员了解系统。

Atlassian 现有的内部剖析的解决方案由与服务一起部署的脚本构成,这些脚本可以使用 Linux perf 或 async-profiler 生成剖析报告。一部分有权限的开发人员(和SRE)可以使用 Amazon System Manager 在生产节点上运行这些脚本。Atlassian 使用 Linux perf 和 async-profiler 具有以下几个优点:

  • 可以可视化为火焰图(易于解释)的格式数据
  • 分析单个进程或整个节点的能力
  • 跨不同维度(如 CPU、内存和I/O)进行分析

Atlassian 最初的连续剖析解决方案包括定期运行 async-profiler(或Linux perf)的预定作业,将原始结果发送给一个微服务,该微服务用于将数据转换为列式数据(Parquet),然后将结果写入Amazon 简单存储服务 (Amazon S3)中。然后在Amazon Glue中定义了一个架构(Schema),允许开发人员使用Amazon Athena查询特定服务的性能剖析数据。Athena使开发人员能够通过编写复杂的SQL查询的方式,筛选一定时间范围内和堆栈帧等维度上的性能剖析数据。Atlassian还构建了一个UI来运行Athena查询,并使用SpeedScope将结果可视化为火焰图。

即使已经为这个解决方案付出了努力,但是仍有大量工作要做,以构建最佳解决方案。同时,Amazon CodeGuru Profiler的发布引起了Atlassian的注意。该服务产品与需求高度相关,并且在很大程度上与现有的能力重叠。经过深入的评估后,Atlassian最终决定停止构建自己的解决方案,转而集成CodeGuru Profiler。为此,他们选择为每个较小的服务定义一个分析组(profiling group)。对于较大的服务,将其被划分为多个分片(每个分片都有单独的自动缩放组),然后为每个分片创建一个分析组。

大家可以通过两种可用模式集成Java Profiler:代理模式和代码模式。为了能够与现有的性能剖析功能集成,同时更好的控制代理,Atlassian决定使用代码模式,从应用程序代码中启动代理。这使他们能够通过现有的功能标志机制控制何时启动(或停止)代理。至此,Atlassian在平台级别集成了CodeGuru探查器,使任何Atlassian服务团队都能够轻松利用此功能。

检查和延迟

Atlassian使用CodeGuru Profiler的第一种场景是识别代码调用路径,这些代码调用路径可以直观的看到CPU利用率或延迟方面的问题。在采集的性能数据中查找不同的形式的同步调用,一个有趣的事情是由Collections.synchronizedMap构成的EnumMap类。以下截图显示此部分代码在24小时中的堆栈帧线程状态监控。

image

尽管所涉及的堆栈跟踪消耗的运行时间不到0.5%,但当进一步观察线程状态的延迟时,可以看到它在BLOCKED状态下花费的时间是RUNNABLE状态的两倍。为了增加在RUNABLE状态下花费的时间比例,我们从使用EnumMap转向使用ConcurrentHashMap的实例。提示:如果大量线程处于BLOCKED,说明CPU一直在等待一些资源的释放才能继续处理,这样造成了CPU的浪费,比如EnumMap由Collections.synchronizedMap构成,它是通过同步的方式实现的,这样会产生大量的锁从而引起线程的BLOCKED。这里我们将其替换为ConcurrentHashMap类来实现,ConcurrentHashMap是通过分段式锁来实现的,相较于Collections.synchronizedMap更高效。

下面的截图显示了类似的24小时内的性能数据。实现更改后,相关的堆栈跟踪现在全部处于RUNABLE状态。

image

建议报告

CodeGuru Profiler还为每个分析组提供了相关的建议报告,从性能角度识别常见的反模式(anti-patterns),并给出已知的建议解决方案。我们收到的一份这样的报告(见下面的截图)强调了我们如何使用JacksonObjectMapper。

image

收到此报告后,我们能够快速的识别问题,并对代码问题进行解决。

结论

通过与CodeGuru Profiler的集成,对我们来说是向前迈出的重要一步,使Atlassian内部的每个开发人员都具备了发现和处理应用性能问题的能力。自启用 CodeGuru Profuler以来,我们已获得以下收益:

  • 任何Atlasian开发人员都可以从任何时间点查找性能状况,从而快速的了解生产中进行的调用路径,以便分析和发现线上的问题。这有助于开发人员了解复杂的应用程序,并在调查性能问题时帮助我们。
  • 大大减少了诊断生产中性能问题的时间,同时我们的开发人员在诊断问题时不再需要注入自定义检测代码。
  • 整个组织中性能监测数据的开放,有助于提高开发人员自行处理性能优化的主动性。

我们对CodeGuru Profiler团队构建的功能感到兴奋,并期待他们接下来将构建的探查技术和功能。

image

阅读 977

亚马逊云AI社区
亚马逊云AI社区是专注于人工智能领域 IT 人士交流与互动的平台。在这里,你可以分享和获取一切有关人工...

亚马逊云科技 AI 开发者社区是专注于人工智能领域,开发者交流与互动的平台。在这里,你可以分享和获取一切有关人工智能的相关技术和前沿知识,也可以与同行或爱好者们交流探讨,共同成长。

2.7k 声望
4.3k 粉丝
0 条评论
你知道吗?

亚马逊云科技 AI 开发者社区是专注于人工智能领域,开发者交流与互动的平台。在这里,你可以分享和获取一切有关人工智能的相关技术和前沿知识,也可以与同行或爱好者们交流探讨,共同成长。

2.7k 声望
4.3k 粉丝
宣传栏