利用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，畢竟不是專業的