常见性能瓶颈、现象及解决方法
1、CPU瓶颈:
- 现象:
整机CPU或者单机能起到的最大个数的处理层进程CPU占用接近或者达到上限,整体CPU接近100%或者单机只能起60个处理层(快速工程化)、单机只能起10个处理层(GPU服务)的进程CPU占用都接近100%
- 常见场景:
通常是CPU计算密集型服务
- 解决办法:
此类通常已达到服务本身的性能上限,反馈开发即可,建议量级处理层单进程CPU75%~85%;想深入了解,可用perf统计函数级的CPU占用时间分布
2、内存瓶颈:
- 现象:
满负载的情况下单进程占用内存很大,整体能起的进程数偏小,能利用到的CPU核数很少。
- 常见场景:
通常是进程需要加载大量的种子信息或者运行过程中需要申请大量的内存做中间存储(文件解析服务等)
- 解决办法:
此类通常已达到服务本身的性能上限,反馈开发即可,建议量级整机内存80%以内;想深入了解,可自行查询内存占用分析相关的工具
3、网卡瓶颈(服务端):
- 现象:
有下载超时量、下载超时量不合理或者到达瓶颈后继续增加并发处理时延大增(在连接超时和下载超时设置很大的情况下会导致服务处理时延大增),查询网卡流量时,网卡流量接近1.25GB/s(万M网卡)
- 常见场景:
大量下载的服务,常见于下载服务、同源视频指纹提取等
- 解决办法:
此类通常已达到服务本身的性能上限,反馈开发即可,建议量级网卡的55%左右
4、磁盘IO瓶颈:
- 现象:
到达瓶颈后继续增加并发处理时延大增,且增大并发时,iotop里的磁盘写速率没有明显增加,iostat里的IO使用率%util超过80%(有待进一步论证)
- 常见场景:
IO密集型服务,有大量写磁盘操作的服务
- 解决办法:
此类通常已达到服务本身的性能上限,反馈开发即可,建议量级磁盘IO的55%左右;想深入了解,可用fio和dd测试磁盘的读写速率
5、GPU瓶颈:
- 现象:
单卡的GPU占用达到100%
- 常见场景:
计算密集型GPU服务
- 解决办法:
此类通常已达到服务本身的性能上限,反馈开发即可,建议量级处理层单进程CPU75%~85%,单卡GPU占用90%左右(前提是batch已调优);
备注:
1、GPU服务通常支持batch,固GPU100%并不一定是GPU服务的吞吐上限,需要调优batch_num和batch_timeout,调优出合适的配置;
2、调整GPU服务的batch会影响单卡的显存占用,GPU显存占用不宜超过80%;
3、GPU单卡进程数的调优尽量控制在GPU占用90%左右时,单进程的CPU占用在75%~85%之间,进程数不可过多,否则服务处理时延增大
6、显存瓶颈:
- 现象:
服务启动加载模型需要申请大量显存(启动时显存占用比运行时显存占用大),导致进程数起的少;服务单进程运行过程中本身占用较大的显存,导致进程数起的少
- 常见场景:
加速模型;模型较大,单进程占用显存较大的服务
- 解决办法:
针对加速模型启动需要申请大量显存的服务,可以调整模型启动是需要申请的显存大小,还可以调整进程串行启动个数(StartConcurrency);单个进程运行时显存占用过大的,可调小batch数,依旧大的话,反馈开发即可
8、显卡功耗瓶颈(降频):
- 现象:
GPU服务稳定性或者爆量时,出现某段时间内超时量较大,功耗超过额定功耗
- 常见场景:
此场景很少(小语种翻译出现过,与机器硬件设备的新旧程度也有关)
- 解决办法:
适当降低建议吞吐
备注:显卡降频的相关信息需要进一步确认,温度、功耗指标受显卡的新旧程度影响很大
9、接入层收发包瓶颈:
- 现象:
服务有超时量,接入层有队列丢弃
- 常见场景:
文本类量级特别大的服务
- 解决办法:
调整接入层的IO线程数
10、接入层预处理瓶颈:
- 现象:
服务有超时量,接入层有队列丢弃
- 常见场景:
接入层预处理多的服务
- 解决办法:
调整接入层的work线程数
11、接入层下载瓶颈:
- 现象:
服务有超时报错或者接入层下载时间特别大(监控平台查看)、日志下载时延特别大
- 常见场景:
接入层大量下载的服务、图片文件类服务
- 解决办法:
调整接入层的download线程数,如果时延允许的话,可适当增加下载链接超时和下载超时
12、locust发包瓶颈:
- 现象:
locust单进程CPU占用超过90%
- 常见场景:
服务回包快,单个locust进程并发过高
- 解决办法:
启用分布式,locust发包加等待时延
13、资源机瓶颈:
- 现象:
服务有下载超时量,服务机网卡未到瓶颈
- 常见场景:
服务下载量大,多人同时共用一台资源机
- 解决办法:
换其他闲置资源机或者错峰压测
14、服务日志:
- 现象:
服务机磁盘增长速度过快,服务性能不及预期
- 常见场景:
服务日志等级设置的太低,服务打印大量无用日志
- 解决办法:
提高日志等级,推荐warn及warn以上级别的日志;如果发现有无用日志,提醒开发修改
15、locust并发分布:
- 现象:
服务进程CPU不均
- 常见场景:
服务多个端口,locust使用分布式
- 解决办法:
如果并发数多的话,不要使用队列取端口号,直接随机取端口号;并发数少的话保证每个slave上的并发数是端口号的倍数即可,可通过加发包时延调整并发数。