《两学一做 榜样》网站站长源码
- 当线上接口的 TP99 突然升高时，意味着该接口在 99% 的情况下响应时间变长，这可能会严重影响系统的性能和用户体验。可以按照下面的步骤进行排查。
- 这里我们先说明一下如何计算tp99：监控系统计算 TP99（第 99 百分位数的响应时间）
- 排序法
数据收集：监控系统会持续收集接口的响应时间数据，这些数据可以是每秒、每分钟或者其他时间间隔内的响应时间样本。
排序：将收集到的一定时间窗口内（如一分钟、一小时等）的所有响应时间数据进行排序，从最小值到最大值排列。
定位 TP99：计算数据总数的 99% 位置所对应的响应时间值。假设在一个小时内收集到了 1000 个响应时间数据点，那么第 990 个位置（1000×99% = 990）的数据值就是 TP99。如果数据点的数量不是整数，可以通过插值的方法来确定 TP99 的值。 - 分桶法
确定桶的范围和大小：将响应时间划分为多个连续的区间，即 “桶”。例如，以 0-100 毫秒、100-200 毫秒、200-300 毫秒等为桶，每个桶有一个固定的范围。
数据分组：将收集到的响应时间数据分配到对应的桶中，统计每个桶内的数据数量。
计算 TP99：从最小的桶开始，依次累加每个桶内的数据数量，直到累加的数量达到或超过总数据量的 99%。此时，当前桶的上限值或者通过在当前桶内进行进一步计算得到的值就是 TP99。
- 排序法
整体分析思路为：先整体后局部。先看整体服务CPU、内存等使用情况；再观察接口流量、调用链路。
1. 确认问题范围
- 监控数据收集：查看接口的监控数据，包括响应时间、吞吐量、错误率等指标的历史数据，确认 TP99 升高是个别接口还是多个接口的普遍问题。
- 业务流量分析：检查业务流量是否有异常波动，例如是否有突发的高并发请求、爬虫攻击等。
2. 应用程序层面排查
- 代码审查
- 近期代码变更：查看最近是否有代码部署到线上环境，尤其是与该接口相关的代码。检查新代码中是否存在性能问题，例如死循环、大量的数据库查询、复杂的计算逻辑等。
- 日志分析：查看应用程序的日志，查找是否有异常信息，如错误堆栈、警告信息等。日志中可能会记录一些导致接口响应时间变长的关键信息。
- 资源使用情况
- CPU 使用率：检查应用程序所在服务器的 CPU 使用率是否过高。如果 CPU 使用率接近 100%，可能是由于代码中存在大量的计算密集型任务或者死循环导致的。
- 内存使用情况：查看应用程序的内存使用情况，是否存在内存泄漏的问题。内存泄漏会导致应用程序的内存占用不断增加，最终影响系统的性能。
- 线程池状态：检查应用程序的线程池配置和状态，是否存在线程池满、线程阻塞等问题。
3. 数据库层面排查
- 慢查询分析
- 数据库日志：查看数据库的慢查询日志，找出执行时间较长的 SQL 语句。可以通过优化这些 SQL 语句，例如添加索引、优化查询条件等，来提高数据库的查询性能。
- 数据库连接池：检查数据库连接池的配置和状态，是否存在连接池满、连接泄漏等问题。
- 数据库性能指标
- CPU 使用率：检查数据库服务器的 CPU 使用率是否过高。
- 磁盘 I/O：查看数据库服务器的磁盘 I/O 情况，是否存在磁盘读写瓶颈。
- 内存使用情况：检查数据库服务器的内存使用情况，是否存在内存不足的问题。
4. 网络层面排查
- 网络延迟
- Ping 命令：使用
ping命令检查应用程序服务器和数据库服务器之间的网络延迟是否正常。 - Traceroute 命令：使用
traceroute命令查看数据包从应用程序服务器到数据库服务器的路由路径，检查是否存在网络拥塞或者丢包的情况。
- Ping 命令：使用
- 网络带宽：检查应用程序服务器和数据库服务器的网络带宽使用情况，是否存在带宽不足的问题。
5. 中间件层面排查
- 负载均衡器：检查负载均衡器的配置和状态，是否存在负载不均衡、转发错误等问题。
- 缓存系统：如果接口使用了缓存系统，检查缓存系统的性能和命中率，是否存在缓存穿透、缓存雪崩等问题。
6. 压测和复现问题
- 模拟高并发：在测试环境中模拟高并发场景，复现 TP99 升高的问题。通过压测工具，如 Apache JMeter、Gatling 等，对接口进行压力测试，观察接口的性能表现。
- 逐步排查：在压测过程中，逐步排除可能的因素，例如关闭某些功能模块、调整配置参数等，找出导致 TP99 升高的具体原因。
补充：线上接口监控tp抖动，有尖刺如何排查？
-
先看接口的监控尖刺对应的机器监控，如果偶发在某几台机器，那可能是gc导致，具体原因需要看对应机器的监控数据。如果发生在某个机房，可能是网络原因导致。
-
如果通过机器看不到特殊信息，那么就需要分析调用链路。是否存在数据库慢、缓存失效、rpc服务耗时抖动等问题。