利用strace系统调用和抓包定位——应用性能问题
背景
某python应用在k8s集群中，调度到某几台机器特别慢。本人被拉去定位该问题，由于不是java应用，不能用javaagent监控定位慢在哪里，本人对python也是一窍不通。遂只能通过更底层的系统调用和抓包来定位慢在哪里
如何排查
- 由于微服务每个服务只起了一个节点，这就相对减少了工作量，所以只要在调用链的pod被调度的主机上attach strace和在对应端口抓包即可。strace所需要的pid可以根据pod内的Pid的关键字在宿主机上找到对应的pid。nohup strace -f -o output.txt -T -tt -e trace=all -p 13554 &
- 微服务的调用链非常简单，用户->A->B，这大大减少了定位的难度。
- A上strace结果，从图中可以看到，A调用了10.106.5.162（B的serviceIp）的get接口，网络层面非常快，耗时0.00003s，后续python代码执行也没用慢的系统调用，大致可以判断问题没有出现在A服务
- B上strace的结果，可以看到poll这条系统调用耗时10S，并且，可以看到这是和mysql在交互，poll在linux系统调用中相当于IO操作，这里指的是网络IO。注：其他系统调用没有看到慢的
同时从系统调用中查看到mysql的地址和端口13306 - 配合抓包验证问题是不是出在调用mysql
- 本来至此，丢给我的任务已经完成，只需要定位慢在哪一步即可。出于好奇，想看看快的机器和慢的机器的包有什么区别。于是，将慢pod调度到快的机器上进行抓包。发现有略微的区别，即U~9h和CP
- 笔者怀疑是openssl的关系，于是查看了openssl和libssl的版本，两台机器都是一样的，好吧，没办法了，甩给DBA，毕竟不是专业的