因收到Google相关通知,网站将会择期关闭。相关通知内容

27 JVM 问题排查分析上篇(调优经验)

一般来说,只要系统架构设计得比较合理,大部分情况下系统都能正常运行,出现系统崩溃等故障问题是小概率事件。也就是说,业务开发是大部分软件工程中的重头戏,所以有人开玩笑说:“面试造火箭,入职拧螺丝。”

一般来说,我们进行排查分析的目的主要有:

  • 解决问题和故障
  • 排查系统风险隐患

我们按照问题的复杂程度,可以分为两类:

  • 常规问题
  • 疑难杂症

常规的问题一般在开发过程中就被发现和解决了,所以线上问题一般会比较复杂,出现在大家都没有考虑到的地方。按照我们的多年解决经验,这些复杂问题的排查方式可以分为两种途径:

  • 逻辑严密的系统性排查;
  • 以猜测来驱动,凭历史经验进行排查。

如果您倾向于选择后一种方式,那么可能会浪费大量的时间,效果得看运气。更糟糕的是,因为基本靠蒙,所以这个过程是完全不可预测的,如果时间很紧张,就会在团队内部造成压力,甚至升级为甩锅和互相指责。

66772038.png

系统出现性能问题或者故障,究竟是不是 JVM 的问题,得从各个层面依次进行排查。

为什么问题排查这么困难?

生产环境中进行故障排查的困难

在生产环境中针对特定问题进行故障排除时,往往会有诸多限制,从而导致排查的过程变得痛苦。

1. 影响到客户的时间越短越好

面对客户的抱怨,解决问题最快的办法可能是:“只要重启机器就能让系统恢复正常”。

用最快的方法来避免对用户产生影响是很自然的需求。

但重启可能会破坏故障现场,那样就很难排查问题的根本原因了。

如果重新启动实例,则无法再采集实际发生的情况,导致我们并没有从这次故障中学习,从而获得收益。

即使重启解决了目前的问题,但问题原因本身仍然存在,一直是一个定时炸弹,还可能会接二连三地发生。

2. 安全方面的限制

接下来是安全性相关的限制,这些限制导致生产环境是独立和隔离的,一般来说,开发人员可能没有权限访问生产环境。如果没有权限访问生产环境,那就只能进行远程故障排除,并涉及到所有与之相关的问题:

  • 每个要执行的操作都需要多人参与或审核,这不仅增加了执行单个操作所需的时间,而且沟通交流过程中可能会丢失一些信息。

特别是将临时补丁程序发布到生产环境时,“希望它能生效”,但这种试错的情况却可能导致越来越糟糕。

因为测试和发布流程可能又要消耗几小时甚至几天,进一步增加了解决问题实际消耗的时间。

如果还需要分多次上线这种“不一定生效的补丁程序”,则很可能会消耗几个星期才能解决问题。

3. 工具引发的问题

还有很重要的一点是需要使用的工具:安装使用的某些工具在特点场景下可能会使情况变得更糟

例如:

  • 对 JVM 进行堆转储(heap dump)可能会使 JVM 暂停几十秒或更长时间。
  • 打印更细粒度的日志可能会引入其他的并发问题,IO 开销、磁盘问题等。
  • 增加的探测器或者分析器可能会有很大开销,导致本就缓慢的系统彻底卡死。

因此,要想给系统打补丁或者增加新的远程监测程序,可能最终会花费很多天的时间:既然在生产环境中进行故障诊断排查会面临这么多的问题,很自然地,大部分情况下,我们都是在开发或测试环境中进行故障排查。

在测试和开发环境进行诊断需要注意的问题

如果在开发环境或者测试环境中进行问题诊断和故障排查,则可以避免生产环境中的那些麻烦。

因为开发环境和生产环境配置不同,有些时候可能也会有问题:即很难复现生产环境中产生的 Bug 或性能问题。

例如:

  • 测试环境和生产环境使用的数据源不同。这意味着由数据量引发的性能问题可能不会在测试环境中重现。
  • 某些问题的使用方式可能不容易复现(我们有时候也称之为“幽灵问题”)。例如只在 2 月 29 日这个特殊时间引起的并发问题,只在多个用户同时访问某个功能时引发,如果事先不知道原因,那也很难排查。
  • 两个环境下的应用程序可能还不一样。生产部署的配置可能明显不同。这些差异包括:操作系统、群集、启动参数,以及不同的打包版本。

这些困难会引起“这不可能,我机器上就没事” 这种很尴尬的局面。

可以看出,因为和实际的生产环境不同,所以在对某些问题进行故障排除时,当前系统环境的性质可能会让你遇到的一些莫名其妙的障碍。

除了特定环境的约束之外,还有其他方面的因素也会导致故障排除过程的不可预测性。

需要做哪些准备工作

本节提供一些处理经验,但是我们希望他们不会成为你的应急措施(就像医生不希望你来医院)。

最好是在平时就先做好全面的系统监控、有针对性的应急预案,并时常进行演练。

掌握行业领域相关的知识

能力可以分为外功和内功。内功就是各种基础知识。外功就是各种工具、技能和技巧。

分析排查问题,需要大量的专业背景知识来支撑。否则你猜都不知道怎么猜,没有方向,也就很难验证正确性了。

想要具备排查复杂问题的能力,至少得对领域行业相关的横向知识有一定的了解,最好还能对所面临的具体问题域有竖向的深刻认识和经验,即所谓的“T”字型人才。

JVM 问题排查需要掌握哪些领域相关的知识呢?下面列出了一些基础:

  • Java 语言功底
  • JVM 基础知识
  • 并发领域知识
  • 计算机体系结构和组成原理
  • TCP/IP 网络体系知识
  • HTTP 协议和 Nginx 等服务器知识
  • 数据库领域知识
  • 搜索引擎使用技巧

以及从这些领域延伸出来的各种技能和技巧。

故障排除是必不可少的过程。只要有人使用的系统,就无法避免地会发生一些故障,因此我们需要很清楚地了解系统的现状和问题。我们无法绕过不同环境带来的困扰,但也不可能“21 天就变成专家”。

在技术开发这个行业,一万小时理论总是成立的。除了累积1万小时的训练时间来成为该领域的专家之外,其实还有更快速的解决方案来减轻故障排除所带来的痛苦。

在开发环境中进行抽样分析

对代码进行抽样分析并没有错,尤其是在系统正式上线之前。

相反,了解应用程序各个部分的热点以及内存消耗,能有效防止某些问题影响到生产环境的用户。

虽然由于数据,使用方式和环境的差异,最终只能模拟生产环境中面临的一部分问题。 但使用这种技术可以预先进行风险排查,如果真的发生问题,可以在追溯问题原因时很快定位。

在测试环境中进行验证

在质量保证领域投入适当的资源,尤其是自动化的持续集成、持续交付流程能及早暴露出很多问题。如果进行周全和彻底的测试,将进一步减少生产环境的事故。但是,这些工作往往得不到资源,“你看功能不是已经完成了吗,为什么还要去花人力物力继续搞,又没有收益”。

实际的工作中,我们很难证明对质量检查的投资是否合理。

一切标有“性能测试”或“验收测试”的产品,最终都将与清晰而可衡量的业务目标(新功能开发)存在竞争。

现在,当开发人员推动“执行某项性能优化”的任务时,如果不能提升优先级,此类任务会积压下来,永远都是待办事项。

为了证明这种投资的合理性,我们需要将投资回报与质量联系起来。如果将生产环境中的P1故障事件减少到80%,可以让我们多产生2倍的收益,在这种情况下,我们就能推动相关人员把这些工作做好。相反地,如果我们不能说明我们改进工作的收益,则我们可能就没有资源去提升质量。

曾经有一个特别形象的例子:农村的孩子为什么不读书?

家长说:因为穷,所以不读书。

那又为什么而贫穷呢?

家长说:因为不读书,所以穷。

在生产环境中做好监控

系统就像是人体一样,只要活着就会在某个时间点生病,所以,我们必须接受的第一件事情就是生产环境一定会出现问题,不管是 Bug 引起的,还是人为操作失误,亦或者天灾导致的。

即使是 NASA/SpaceX 这种高端组织也会不时地炸几艘飞船火箭,因此我们需要为线上发生的问题做好准备。

无论怎么分析和测试,总会有些漏掉的地方,事故就在这些地方产生。

既然无法避免总会需要对生产环境进行故障排除。为了更好地完成手头的工作,就需要监控生产环境中系统的状态。

  • 当出现问题时,理想情况下,我们已经拥有了足以解决该问题的相关信息。
  • 如果已经拥有了所需的信息,则可以快速跳过问题复现和信息收集的步骤。

不幸的是,监控领域并没有万能的银弹。即使是最新的技术也无法提供不同场景下的所有信息。

典型的 Web 应用系统,至少应该集成下面这些部分:

  • 日志监控。汇总各个服务器节点的日志,以便技术团队可以快速搜索相关的信息,日志可视化,并进行异常报警。最常用的解决方案是 ELK 技术栈,将日志保存到 Elasticsearch 中,通过 Logstash 进行分析,并使用 Kibana 来展示和查询。
  • 系统监控。在基础架构中汇总系统指标并进行可视化查询,既简单又有效。关注CPU、内存、网络和磁盘的使用情况,可以发现系统问题并配置监控报警。
  • 系统性能监控(APM,Application Performance Monitoring),以及用户体验监控。关注单个用户的交互,能有效展示用户感受到的系统性能和可用性问题。至少,我们可以知道是哪个服务在哪段时间发生了故障。比如集成 Micrometer、Pinpoint、Skywalking、Plumbr 等技术,能快速定位代码中的问题。

确保在系统发布之前已经在开发环境中进行过系统性能分析,并经过测试验收,从而减少生产故障。

了解生产部署环境并做好监控,当故障发生时,我们就能可预料的方式,更快地做出响应。

自上而下划分 JVM 问题

前面的小节讲了一般的问题诊断和调优套路:

做好监控,定位问题,验证结果,总结归纳。

下面我们看看 JVM 领域有哪些问题.

47867364.png

从上图可以看到,JVM 可以划分为这些部分:

  • 执行引擎,包括:GC、JIT 编译器
  • 类加载子系统,这部分的问题,一般在开发过程中出现
  • JNI 部分,这部分问题一般在 JVM 之外
  • 运行时数据区;Java 将内存分为 2 大块:堆内存和栈内存

对这些有了了解,在我们进行知识储备时,就可以按照自顶向下的方式,逐个攻克。

线上环境的JVM问题主要集中在 GC 和内存部分。而栈内存、线程分析等问题,主要是辅助诊断 Java 程序本身的问题。

相关的知识点,如果有不清楚的地方,请各位同学回过头来,再读一读前面的章节。

我认为这些基础的技术和知识,需要阅读和练习 2~3 遍,才会掌握的比较牢固;毕竟理解和掌握了才是自己的。

标准 JVM 参数配置

有读者朋友提问:

我希望能在课程中总结一下,JVM 的参数设置,应该按照哪些步骤来设置?

截止目前(2020 年 3 月),JVM 可配置参数已经达到 1000 多个,其中 GC 和内存配置相关的 JVM 参数就有 600 多个。从这个参数比例也可以看出,JVM 问题排查和性能调优的重点领域还是 GC 和内存。

参数太多是个大麻烦,让人难以下手,学习和理解起来也很费事。

但在绝大部分业务场景下,常用的 JVM 配置参数也就 10 来个。

我们先给一个示例,读者可根据需要适当增减。

# 设置堆内存
-Xmx4g -Xms4g 
# 指定 GC 算法
-XX:+UseG1GC -XX:MaxGCPauseMillis=50 
# 指定 GC 并行线程数
-XX:ParallelGCThreads=4 
# 打印 GC 日志
-XX:+PrintGCDetails -XX:+PrintGCDateStamps 
# 指定 GC 日志文件
-Xloggc:gc.log 
# 指定 Meta 区的最大值
-XX:MaxMetaspaceSize=2g 
# 设置单个线程栈的大小
-Xss1m 
# 指定堆内存溢出时自动进行 Dump
-XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=/usr/local/

这些参数我们在前面的章节中都介绍过。

此外,还有一些常用的属性配置:

# 指定默认的连接超时时间
-Dsun.net.client.defaultConnectTimeout=2000
-Dsun.net.client.defaultReadTimeout=2000
# 指定时区
-Duser.timezone=GMT+08 
# 设置默认的文件编码为 UTF-8
-Dfile.encoding=UTF-8 
# 指定随机数熵源(Entropy Source)
-Djava.security.egd=file:/dev/./urandom 

一份简单的问题排查手册

一般人的排查方式

如果使用自己熟悉的工具,并且对于故障排除的规则已经胸有成竹,那么环境限制就不再是什么大问题。

实际上,负责排查和解决问题的工程师通常没有预先规划好的处理流程。

老实说,大家是否有过像下面这样的 shell 操作:

# 查看当前路径
pwd

# 查看当前目录下有哪些文件
ls -l

# 查看系统负载
top

# 查看剩余内存
free -h

# 查看剩余磁盘
df -h

# 查看当前目录的使用量
du -sh *

# 系统活动情况报告
sar
-bash: sar: command not found

# Linux安装sysstat
# apt-get install sysstat
# yum -y install sysstat

# 查看帮助手册
man sar

# 查看最近的报告
sar 1

# ???
sar -G 1 3
sar: illegal option -- G

# 查看帮助手册
man sar

# ......

如果您觉得上面这个过程很熟悉,别紧张,其实大家都这样干。

大多数工程师在故障排除和诊断调优领域都缺乏经验,因此也就很难使用标准的套路。

这没什么丢人的——除非是 Brendan Gregg or Peter Lawrey 这种专业大牛,否则您很难有 1 万小时的故障排除经历,也就很难成为这个领域的专家。

缺乏经验的话,针对当前问题,往往需要使用不同的工具来收集信息,例如:

  • 收集不同的指标(CPU、内存、磁盘 IO、网络等等)
  • 分析应用日志
  • 分析 GC 日志
  • 获取线程转储并分析
  • 获取堆转储来进行分析

最容易排查的是系统硬件和操作系统问题,比如:CPU、内存、网络、磁盘 IO。

我们可以使用的工具几乎是无限的。与实际解决问题相比,使用各种不熟悉的工具,可能会浪费更多的时间。

以可量化的方式来进行性能调优

回顾一下,我们的课程介绍了可量化的 3 个性能指标:

  • 系统容量:比如硬件配置、设计容量;
  • 吞吐量:最直观的指标是 TPS;
  • 响应时间:也就是系统延迟,包括服务端延时和网络延迟。

也可以具体拓展到单机并发,总体并发、数据量;用户数、预算成本等等。

一个简单的流程

不同的场景、不同的问题,排查方式都不一样,具体怎么来确定问题是没有固定套路的。

可以事先进行的操作包括:

  • 培训:提前储备相关领域的知识点和技能、工具使用技巧等等。
  • 监控:前面提到过,主要是 3 部分,业务日志、系统性能、APM 指标。
  • 预警:在故障发生时,及时进行告警; 在指标超过阈值时进行预警。
  • 排查风险点:了解系统架构和部署结构,分析单点故障、扩容瓶颈等等。
  • 评估系统性能和服务级别:例如可用性、稳定性、并发能力、扩展性等等。

各家公司可能有自己的事故处理规范,可能会涉及这些因素:

  • 相关人员:包括开发、运维、运营、QA、管理人员、客服等等。
  • 事故级别,严重程度,影响范围、紧急程度。
  • 汇报、沟通、咨询。
  • 问题排查,诊断、定位,监控、分析
  • 事故总结、分析原因、防止再现。
  • 改进和优化、例如使用新技术、优化架构等等。

可以进行排查的点

\1. 查询业务日志,可以发现这类问题:请求压力大、波峰、遭遇降级、熔断等等,基础服务、外部 API 依赖。

\2. 查看系统资源和监控信息:

  • 硬件信息、操作系统平台、系统架构
  • 排查 CPU 负载
  • 内存不足
  • 磁盘使用量、硬件故障、磁盘分区用满、IO 等待、IO 密集、丢数据、并发竞争等情况
  • 排查网络:流量打满,响应超时,无响应,DNS 问题,网络抖动,防火墙问题,物理故障,网络参数调整、超时、连接数

\3. 查看性能指标,包括实时监控、历史数据。可以发现假死、卡顿、响应变慢等现象。

  • 排查数据库,并发连接数、慢查询、索引、磁盘空间使用量、内存使用量、网络带宽、死锁、TPS、查询数据量、redo 日志、undo、binlog 日志、代理、工具 Bug。可以考虑的优化包括:集群、主备、只读实例、分片、分区。
  • 大数据、中间件、JVM 参数。

\4. 排查系统日志,比如重启、崩溃、Kill。

\5. APM,比如发现有些链路请求变慢等等。

\6. 排查应用系统:

  • 排查配置文件:启动参数配置、Spring 配置、JVM 监控参数、数据库参数、Log 参数、APM 配置。
  • 内存问题,比如是否存在内存泄漏,内存溢出、批处理导致的内存放大、GC 问题等等。
  • GC 问题,确定 GC 算法、确定 GC 的KPI,GC 总耗时、GC 最大暂停时间、分析 GC 日志和监控指标:内存分配速度,分代提升速度,内存使用率等数据。适当时修改内存配置。
  • 排查线程,理解线程状态、并发线程数、线程 Dump,锁资源、锁等待、死锁。
  • 排查代码,比如安全漏洞、低效代码、算法优化、存储优化、架构调整、重构、解决业务代码 Bug、第三方库、XSS、CORS、正则。
  • 单元测试:覆盖率、边界值、Mock 测试、集成测试。

\7. 排除资源竞争、坏邻居效应

\8. 疑难问题排查分析手段:

  • DUMP 线程
  • DUMP 内存
  • 抽样分析
  • 调整代码、异步化、削峰填谷

总之,时至今日,软件领域的快速发展,使得我们可以使用的手段和工具,都很丰富。勤学苦练,掌握一些常见的套路,熟练搭配应用一些工具,是我们技术成长,能快速解决问题的不二法门。