I/O分析系列--filetop(查看系统内核对文件读写情况)+opensnoop(查看系统调用打开的所有文件)对文件系统/磁盘IO导致系统反应慢的问题分析

I/O分析系列--filetop(查看系统内核对文件读写情况)+opensnoop(查看系统调用打开的所有文件)对文件系统/磁盘IO导致系统反应慢的问题分析

目录

1.查看请求接口时的时延:

2.使用压力工具请求服务时查看系统负载:top

• ​ 发现cpu,mem正常,iowait高.

3.iostat查看系统io负载

• ​ 发现此磁盘sda的I/O使用率已经达到100%饱和

4.df查看sda是否是磁盘设备

​ df -h---->确认是系统磁盘

5.pidstat排查是哪个进程引起I/O瓶颈

6.strace -p pid跟踪该进程的系统调用

7.filetop -C跟踪内核中文件的读写情况.

8.ps -efT | grep 35879:

• ​ 发现子线程属于我们的压测程序.

9.opensnoop查看系统调用打开的所有文件

10.进入/tmp目录,查看这些文件:

11.结合filetop和opensnoop发现:

• ​ 该进程下的子线程会写入大量的txt文件,然后把这些文件数据读到内存中然后删除

12.分析代码问题:证实猜想

• ​ 确实有文件的写操作.

13.问题定位分析:

• ​ 应用程序动态生成的这一批文件,用来临时存储数据,由于这些临时文件的读写,导致了I/O瓶颈,导致整个系统非常慢.

14.总结:

1. 先top.iostat分析系统的cpu和磁盘使用情况,发现了I/O瓶颈.

2. 定位产生I/O瓶颈的应用.

3. 用strace跟踪系统调用(本次没发现wirte的系统调用).

4. 用动态跟踪工具包bcc中的filetop,opensnoop定位应用产生瓶颈的原因(发现大量临时文件的读写,导致I/O瓶颈,拖累系统).

1.查看请求接口时的时延:

2.使用压力工具请求服务时查看系统负载:top

发现cpu,mem正常,iowait高.

3.iostat查看系统io负载

发现此磁盘sda的I/O使用率已经达到100%饱和

4.df查看sda是否是磁盘设备

df -h---->确认是系统磁盘

5.pidstat排查是哪个进程引起I/O瓶颈

​ pidstat -d 3--->发现进程7862有大量的写请求(KB_wr/s),确认该进程导致了磁盘I/O负载瓶颈.

6.strace -p pid跟踪该进程的系统调用

​ strace -p 7862--->发现全是stat调用,该进程没有调用wirte系统函数.排除进程的系统调用导致IO瓶颈.

7.filetop -C跟踪内核中文件的读写情况.

​ filetop -C:输出时不清空屏幕.观察一段时间,发现线程35859在间隔性的写数据,然后再读数据

8.ps -efT | grep 35879:

发现子线程属于我们的压测程序.

9.opensnoop查看系统调用打开的所有文件

​ ./opensnoop--->找到这些临时文件路径.

10.进入/tmp目录,查看这些文件:

​ cd /tmp/***--->提示:No such file or directory ,说明这些数据文件都是应用程序动态生成的.

11.结合filetop和opensnoop发现:

该进程下的子线程会写入大量的txt文件,然后把这些文件数据读到内存中然后删除

12.分析代码问题:证实猜想

确实有文件的写操作.

13.问题定位分析:

应用程序动态生成的这一批文件,用来临时存储数据,由于这些临时文件的读写,导致了I/O瓶颈,导致整个系统非常慢.

14.总结:

1. 先top.iostat分析系统的cpu和磁盘使用情况,发现了I/O瓶颈.

2. 定位产生I/O瓶颈的应用.

3. 用strace跟踪进程的系统调用(本次没发现进程有wirte的系统调用,说明IO不是来自于进程,而是来自系统内核).

4. 用动态跟踪工具包bcc中的filetop(查看系统内核对文件的读写情况),opensnoop(查看系统调用打开的所有文件)定位应用产生瓶颈的原因(发现大量临时文件的读写,导致I/O瓶颈,拖累系统).