Linux性能优化实战 26-27：磁盘I/O故障的两个例子

例子一、疯狂写日志导致 iowait 超过了 90%

1. top命令查询状态

   发现CPU0的 wa (iowait)非常之大，属于异常。

2. iostat 查询磁盘状态

每秒写磁盘请求数是 64 ，写大小是 32 MB，写请求的响应时间为 7 秒，而请求队列长度则达到了 1100。

超慢的响应时间和特长的请求队列长度，进一步验证了 I/O 已经饱和的猜想。

3. pidstat 查询进程状态

明显，正是 python 进程导致了 I/O 瓶颈。

4. strace 命令查看进程运行堆栈

进程向文件描述符编号为 3 的文件中，写入了 300MB 的数据。正在获取 文件 /tmp/logtest.txt.1 的状态。

5. lsof 命令，看看进程 18940 都打开了哪些文件

进程打开了文件 /tmp/logtest.txt，并且它的文件描述符是 3 号，而 3 后面的 w ，表示以写的方式打开。

得出问题的根源：进程 18940 以每次 300MB 的速度，在“疯狂”写日志，而日志文件的路径是/tmp/logtest.txt。

6. 解决方案： 把日志级别从 info 改为 error。  (这并不是本文章关键)

 

例子二、大量写临时文件导致iowait超过90%

1. top命令查询状态

   发现CPU0的 wa (iowait)非常之大，属于异常。

2. iostat 查询磁盘状态

磁盘 sda 的 I/O 使用率已经达到 98% ，写请求的响应时间高达 18 秒，每秒的写数据为 32 MB，显然写磁盘碰到了瓶颈。

3. pid查看进程状态

问题进程是python

4. strace 命令查看进程运行堆栈

    有大量stat调用，但无write调用，未找出问题所在。

5. filetop输出线程 ID（TID）、读写大小、读写类型以及文件名称。

线程号为 514 的 python 应用就会先写入大量的 txt 文件，再大量地读。

6. 确认514线程属于哪个应用

正是案例应用 12280 的线程

7. opensnoop动态跟踪内核中的 open 系统调用

 文件位于 /tmp/9046db9e-fe25-11e8-b13f-0...

8. 检查该目录下的文件状况

目录居然不存在了

 9.再执行 opensnoop跟踪

目录名已经改了。

可以判断，案例应用会动态生成一批文件，用来临时存储数据，用完就会删除它们。

得出问题的根源：这些临时文件读写，引发了 I/O 的性能瓶颈.

10. 解决方案： 把使用临时文件的方式，改为使用内存的方式。