线上接口响应慢如何排查

线上接口响应慢如何排查？

常见排查手段

慢查询日志

1. sql 性能瓶颈
   • slow_query_log 慢查询开关
   • slow_query_log_file 慢查询日志存放的路径
   • long_query_time 超过多少秒才会记录日志
2. 监控指标
   • 系统性能指标 包括请求成功率 系统吞吐量 响应时长
   • 资源性能指标 衡量系统硬件资源使用请求 配合系统性能指标 观察系统资源水位
3. Log日志
   • 施压引擎日志 观察施压引擎是否健康，压测脚本执行是否有报错
   • 采样日志 采样记录API的请求和响应详情 辅助排查压测过程中的一些出错请求参数是否正常，并通过响应详情 查看完整的错误信息
4. Traces 分布式链路追踪
   • 用于性能问题诊断 通过追踪请求在系统中的调用链路 定位报错API的报错系统和报错堆栈 快速定位性能问题点。
5. 压测监控核心指标
   • 压测过程中 对系统硬件 中间件 数据库资源的监控 包括系统性能指标 资源指标 中间件指标 数据库指标 前端指标 稳定性指标 批量处理指标 可扩展性指标 可靠性指标等。
     • 系统性能指标
       • 交易想要时间 RT 500ms
     • 系统处理能力
       • HPS 每秒点击数
       • TPS 系统每秒处理数
       • QPS 系统每秒查询数
     • 错误率
       • 在负载的情况下 失败交易的概率 错误率 = （失败交易/交易总数） * 100% 错误率应该由超时引起 即为超时率
     • 资源指标
       • CPU
         • 不能超过100% cpu 利用率 80% 告警 如果持续增长不能立即处理 考虑故障转移 剔除服务 保留现场证据进行分析定位
       • Memory
         • 不能超过100% 80%占用告警 观察gc日志 持续增长 不能降低 考虑故障转移 剔除服务 保留现场证据进行分析定位
       • 磁盘吞吐量
         • 不能超过100% 80% 占用告警 持续增长 不能降低 考虑故障转移 剔除服务 保留现场证据进行分析定位（正常业务 考虑扩容）
       • 网络吞吐量
         • 不能将带宽打满100% 80% 告警 不能降低 考虑增加带宽 进行问题定位 保证业务正常响应
     • 中间件指标

       • GC

         • GC 频率 每秒多少次
         • Full GC 频率 每小时多少次
         • Full GC 平均时长
         • Full GC 最大时长
         • 堆使用率 百分比

       • ThreadPool

         • active thread pool 活动的线程数
         • pending user request 处于排队的用户请求个数
         • JDBC jdbc active connection JDBC 活动链接数

       • 数据库指标

         一级指标	二级指标	单位	含义
         SQL	耗时	微妙	执行SQL耗时
         吞吐量	QPS	个	每秒查询次数
         吞吐量	TPS	个	每秒事务次数
         命中率	Key Buffer命中率	百分之	索引缓冲区命中率
         命中率	InnoDB Buffer命中率	百分之	InnoDB缓冲区命中率
         命中率	Query Cache命中率	百分之	查询缓存命中率
         命中率	Table Cache命中率	百分之	表缓存命中率
         命中率	Thread Cache命中率	百分之	线程缓存命中率
         锁	等待次数	次	锁等待次数
         锁	等待时间	微妙	锁等待时间

       • 稳定性指标

         • TPS 曲线稳定 没有大幅度的波动
         • 各项资源指标没有泄漏或异常的情况

       • 可扩展性指标

         • 计算公式：(增加性能/原始性能) / （增加资源/原始资源） * 100%
         • 接口响应时间
         • 调用第三方服务耗时
         • 慢查询sql耗时
         • cpu使用情况
         • 内存使用情况
         • 磁盘使用情况
         • 磁盘使用情况
         • 数据库使用情况

接口响应慢

1. 大量接口都很慢
2. 页面打不开
3. 监控告警 短信提醒

排查步骤

1. 是否CPU使用过高
2. 是否内存占用过高
3. 是否磁盘占用过高
4. 是否网络故障
5. 查看后台日志
6. 是否是数据库问题（比如索引，死锁）
7. 是否是垃圾回收导致

• CPU占用过高
  • 定位进程 top
  • 定位线程 top -Hp
  • 定位代码位置 jstack
    a. print %x 4519
    b. jstack 1893 | grep 11a7 -A 30 -color
  • 常见原因
    • 无限循环
      • 递归逻辑错误或数据库数据错乱导致。
    • 频繁GC
      • 访问量大 内存分配快 导致GC线程频繁工作。
      • jstat -gcutil pid 1000 查看堆内存各区域的使用率以
    • 序列化和反序列化
      • 大量数据进行序列化和反序列化
    • 正则表达式
      • 复杂的正则表达式
      • 处理大量文本数据
      • 表达式错误导致进行大量回溯
    • 频繁的上下文切换
  • 内存占用过高
    • 定位Java程序内存使用过高或者内存泄漏问题
    • top
    • top -Hp
    • jmap -dump:format=b,file=dump.hprof 1427
    • jmap -histo pid | head -n20 查看堆内存中的存活对象
    • 故障转移 剔除服务 dump文件进行分析
  • 磁盘问题
    • df du
    • iostat
      • 命令用于报告 CPU 使用情况和磁盘 I/O 统计信息
      • 关键指标及其含义
        • %util 设备利用率 表示一秒中有百分之多少的时间用于I/O操作。
        • await 平等待时间 每个 I/O 请求的平均等待时间（包括排队时间和实际服务时间）。如果 await 远大于 svctm（平均服务时间），则表明 I/O 队列太长，应用程序响应变慢。对于 HDD 来说，如果 await 超过 20ms，通常认为是不正常的磁盘性能
        • svctm (平均服务时间)：虽然某些版本中不再提供此字段，但它反映了平均每次 I/O 操作的服务时间。如果 svctm 大于 15ms 并且 %util 接近 100%，这可能是磁盘成为系统性能瓶颈的一个信号
        • r_await 和 w_await：分别代表读取和写入操作的平均等待时间。这两个值可以帮助我们进一步区分读写操作各自的延迟特性
        • avgqu-sz (平均队列长度)：平均 I/O 队列长度。较大的 avgqu-sz 可能意味着有大量 I/O 请求正在等待处理，这也可能是 I/O 系统压力大的一个标志
        • iowait (CPU 等待 I/O 完成的时间百分比)：高比例的 %iowait 表明 CPU 在等待 I/O 操作完成上花费了较多时间，这可能是由于磁盘 I/O 性能不佳造成的
        • kB/s 和 wkB/s：每秒从设备读取的数据量和每秒向设备写入的数据量。异常高的读写速率可能提示存在频繁的大规模数据传输活动，需要检查是否有不必要的大文件拷贝或其他导致大量 I/O 的进程
        • rrqm/s 和 wrqm/s：每秒合并的读请求数和写请求数。较高的合并率说明内核有效地减少了物理 I/O 次数，但如果合并率突然下降，可能是 I/O 模式发生了变化，比如从顺序访问变为随机访问
    • vmstat
      • 命令用于报告虚拟内存统计信息
    • lsof
      • 命令用于列出打开文件。