利用strace系统调用和抓包定位——应用性能问题

背景

某python应用在k8s集群中,调度到某几台机器特别慢。本人被拉去定位该问题,由于不是java应用,不能用javaagent监控定位慢在哪里,本人对python也是一窍不通。遂只能通过更底层的系统调用和抓包来定位慢在哪里

如何排查

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

你可能感兴趣的:(日常)