在并发量一定的情况下如何对系统响应时间进行详细分析

分析步骤
1.1 在关键点位添加日志信息 -> 缩小目标范围

a) 主要函数耗时

b) 访问外部系统耗时:DB、MQ、Cache、FileSystem、RPC、HTTP等

c) 接口内不同逻辑耗时百分比/绝对值

1.2 详细分析瓶颈出现原因

a) 技术层面:优先考虑

b) 业务逻辑:业务逻辑改造一般影响较大、耗时较长,优先级低

1.3 针对性解决问题

一旦定位了问题原因,解决问题的方法都相当容易

技术层面
2.1 代码实现

a) 串行逻辑是否可以并行化

b) 串行请求是否可以批量(batch)请求

c) SQL是否需要优化

d) 算法复杂度是否需要优化

e) 语言核心库是否提供了性能更高的使用方式

f) 引用的第三方库是否存在性能问题

g) 每次外部请求是否都重新建立连接

2.2 内核/硬件层面

a) CPU使用率

b) 内存使用率

c) 磁盘IO状况

d) 网络状况

d) 瓶颈是否由调用的内核函数引起?

该函数是如何工作的;新版本内核是否已经对此优化;如何调整使用方式可以更高效

2.3 日志

线程会争夺日志锁,在高并发情况下,同步写日志很影响性能。异步写又可能引起OOM。

业务逻辑
随着业务的增长,接口负担的功能原来越复杂,逻辑链路越来越长,事务越来越大,性能越来越差,越来越没办法维护。(如果有人负责把控、从相对长远些的角度设计系统的迭代,这种情况本是可以避免的)

优化办法只有一个就是:保留主链路,旁支链路异步化。

常用工具
4.1 内核

a) CPU: top、vmstat htop w uptime dstat

b) MEM: top、free

c) disk IO: iostat

例: iostat -kx 1 //每秒统计一次io

iotop -o //查看磁盘使用率较高的进程

d) 网络

流量:sar -n DEV 1 3 //每秒统计一次所有网卡流量,共3次

网络抓包: tmpdump,可配合tmptrace、wireshark分析

TCP连接状况:netstat -an | grep TIME_WAIT //client端近期关闭tcp连接数量

e) 查看/proc/xxx中的系统详细信息

小知识
a) 网络抖动引起tcp重传,一般内部系统之间的调用,linux设置的重传时间间隔为至少200ms以上。

b) 服务之间通过网络调用,网络开销在500us ~ 2ms

c) 机械磁盘寻址: 20ms

d) 磁盘的某page中如果存在数据,程序写此page时如果不会填充整个page,内核会先载入整个page,再输出整个page,保证磁盘数据不丢。这会导致一次被动读磁盘,性能损耗会很大。否则会直接写入磁盘高速缓存,间隔固定时间刷盘一次(5s)。

e) 日志使用seaslog buffer

随着系统并发量的增加,系统响应时间会逐步下降甚至雪崩,一般是由多线程之间、模块之间、子系统之间争夺资源(锁)引起的。


guanhui07
792 声望11 粉丝

修复这个bug


下一篇 »
后端技术图谱