最近在生产上，有实时计算的torm机器的磁盘oiwait间断性升高。这不是很正常的现象，storm 的数据直接通过网络进入内存，数据在内存流转。也就是storm并不会大量的读写磁盘文件，除了storm的Topology的日志会写到磁盘上，strom机器上也没有运行其他的应用程序。到底哪些进程占用了大量的磁盘io，导致iowait升高。

1、iotop

结果显示kjournald进程占用的io资源最多，而多个java进程也占用了一部分io资源。

2、通过proc查看

cut -d" " -f 1,2,42 /proc/*/stat | sort -n -k +3 1000 (kswapd1) 930 999 (kswapd0) 2392 12401 (pdflush) 31551 12504 (pdflush) 42807 1720 (kjournald) 60460112iotop显示kjournald占用了10%IO资源，占用最多。 而proc里面的数据也显示，pdflush也写入了大量数据到磁盘文件上。

3、ext3系统日志

kjournald是ext3文件系统的日志进程，负责记录ext3文件系统的数据更新日志。ext3的日志有三种级别：

•1）journal：记录文件系统的文件数据和元素（metadata）的更新。•2）ordered：只记录文件系统的元数据的更新日志，但是在元数据发生变更之前，把日志写入磁盘。ordered是ext3的默认日志级别。•3）writeback：如果你了解raid卡的写入级别，那么也很容易理解这个writeback的含义。writeback级别下，同样只会记录metadata的更新日志。但是没有强制日志在metadata更新之前把数据写入到磁盘上，什么时候写入磁盘取决于标准文件系统（操作系统）进行flush脏页操作。

4、pdflus和kswapd守护进程

pdflush和kswapd进程 在使用top和ps的时候，可以经常看到这两个线程。pdflush进程的作用是同步内存数据到磁盘，保证内存的数据和磁盘的数据一致，把内存中脏页（dirty page）写入到磁盘上。kswap的作用是管理内存，保证系统内存能够满足任何用户需求。系统每过一定时间就会唤醒kswapd，看看内存是否紧张，如果不紧张，则睡眠，在kswapd中，有2个阀值,pages_hige和pages_low,当空闲内存页的数量低于pages_low的时候,kswapd进程就会扫描内存并且每次释放出32个free pages,直到free page的数量到达pages_high.

5、iowait的元凶

•1）ext3（kjournald）记录了大量的日志，而且日志需要强制写入到磁盘（pdflush进程）。•2）从fstab文件可以看出，系统的日志级别为ordered，而且文件系统挂载使用的默认挂载参数，没有做任何优化。

cat /etc/fstab LABEL=/ / ext3 defaults 1 1 LABEL=/boot /boot ext3 defaults 1 2

•3）storm机器上只有storm topology进程。topology进程读写日志文件，更改了metadata文件。

6、磁盘参数优化

磁盘的挂载参数进行优化，增加noatime选项（nodiratime可以不加）。noatime可以提高磁盘5%-10%的读写性能。

LABEL=/ / ext3 defaults,noatime 1


来源：
http://mdba.cn/2015/04/06/%e5%a6%82%e4%bd%95%e5%af%bb%e6%89%beiowait%e5%85%83%e5%87%b6/