看到實驗內容時，我會心一笑，感覺還是上次的流程
pidstat查找到導致io性能的進程號
然後strace查看到讀寫文件的系統調用write
然後查看源代碼就能定位到源代碼行數
然後，我就被打臉了，啪啪啪的
iostat 已經證明磁盤 I/O有性能瓶頸，而 pidstat 也證明了某個進程引起的，但 strace 跟蹤這個進程，卻沒有找到任何 write 系統調用。
新工具filetop
基於Linux內核的eBpf機制，主要跟蹤內核中文件的讀寫情況，並輸出線程id，讀寫大小，讀寫類型以及文件名稱等。
通過filetop輸出查找到可疑的線程
ps -efT | grep 514
新工具opensnoop
同樣屬於bcc軟件包，可以動態跟蹤內核中的open系統調用。這樣，就可以找出這些txt文件的路徑。
這時我們已經能初步定爲到問題了，案例會動態生成一批文件，用來臨時存儲數據，用完會刪除它們。但不幸的是，正是這些文件讀寫，引起了IO的性能瓶頸，導致了整個處理過程非常慢。
如何來驗證這個猜想呢？當然是查看源代碼了，哈哈