junior77的专栏

pyton服务进程CPU占用率高问题定位、分析

混合场景压测时，发现通过增加线程数、扩容被测服务数量等，服务整体吞吐量最大到TPS 1.6万左右，不会随着线程的增加、服务容器数量增加而增长，且增加线程后，接口耗时开始增加。redis分片带宽调整后，回归压测，确认服务吞吐量上来了（QPS 29000，预期QPS 20000，已满足预期），接口耗时在100ms内，各服务资源使用正常。经排查，发现redis集群（共8个分片）的其中一个分片带宽比其他7个分片，出网带宽要高90MB。通过断点日志打印，发现耗时超过200ms的为redis查询key的操作。

参考下图，Latency time - Connection time 值较大（20000ms以上），可以判定时间主要消耗在服务层，需要进一步分析。问题现象：近期发现每晚跑的定时压测任务，压测结果中，各接口耗时变高（原来99耗时20秒)。发现 Latency time 延迟时间较高，Connection time 建立连接时间 较小。Connection time 建立连接时间。Latency time 延迟时间。

接口性能 优化方向 优化实战

觉得不错，转载下。

使用火焰图定位性能问题

问题现象：某项目压测时，半小时后发现交易批量失败。查看业务日志发现 redis失去连接2021/04/01 14:00:11 [error] [exception.Predis\Connection\ConnectionException] exception 'Predis\Connection\ConnectionException' with message 'Connection timed out [tcp://127.0.0.1:6379]' in/opt/www/source/in.

年轻的时候，经常听一些大会或者演讲。有些人说，思路逻辑非常重要。我那时就想，你肯定是瞎忽悠的，因为我怎么就没听懂你说的思路呢？而现在轮到自己来写或者讲一些东西的时候，才发现他们说得很对，而我之所以不理解，也是有原因的。性能分析思路和具体的实现之间，有一道鸿沟，那就是操作的能力。之前我为什么听不懂那些人的思路，其实是因为我没有操作的功底。而有了操作的功底之后，还有一个大的鸿沟要越过去，那就是从操作到对监控计数器的理解。这一步可以说让很多性能测试人员都望而却步了。但是这还不算完，这一步迈过去之后

1、服务器CPU飙高2、tp99毛刺3、服务器内存泄漏4、可用率下降

问题描述：某系统单交易多并发运单下发时，耗时为1340ms。问题分析：发现OMS对com.jd.eclp.master.dept.service.DeptService:getDept方法重复调用了4次（同一deptid），累计耗时：129ms。 注：系统方法调用监控使用的是pinpoint。优化方案：减少OMS系统对getDept方法的调用次数，可优化为调用一次即可。...

问题描述：单应用单交易场景下，订单－新增在250并发压力下某系统后台报以下错误。[] WARN 2019-01-08 13:44:52,957 [JSF-SEV-WORKER-123-T-9] com.jd.jsf.gd.server.BusinessPool.rejectedExecution(128) | [JSF-23002]Task:java.util.concurrent.FutureTask@3a1046d9 has been reject for ThreadPool exhausted! .

问题描述：某仓储系统压测时，发现任务分配worker后台定时处理任务时(积压2个已定位波次,每波次10000订单)，ta-worker应用后台抛出”组建集合单异常”,错误信息如下：2018-10-22 14:09:29[ schedulerFactoryBean_Worker-1:1936704 ] - [ERROR] com.jd.wms.assign.worker.TaskAssignWorker-: - [TaskAssignWorker] ：{}java.lang.OutOfMemoryErro

分享下之前项目性能测试时遇到的各种性能问题及解决思路、方法，欢迎同行交流！经了解，波次定位包含：调用。波次定位时，单波次无积压。采用多线程方式，需注意对。次，且每次调用耗时约。2）波次定位TPS由。

问题描述：在对某仓储系统运单WaybillAddAPI.add接口压测时,发现数据库CPU资源占用为85.05(23%us;62%sy),sys占用较高。问题分析：mysql中大量写入字段为timestamp 类型数据，当time_zone 设置为 system 时，mysql 访问每一行的 timestamp 字段时，都会通过 libc 的时区函数，获取 Linux 设置的时区，在这个函数中会持有mutex，当大量并发SQL需要访问 timestamp 字段时，会出现 mutex 竞争。MySQL 中

性能问题诊断篇-服务器CPU

性能问题诊断篇-应用线程

性能问题诊断篇-数据库死锁

性能问题诊断篇-数据库索引

性能问题诊断篇-log4j

性能问题诊断篇- 服务器磁盘