经常我们碰到一些问题,进程的写文件,写入的速度非常慢,而且当时总的IO的数量(BI,BO)也非常低,但是vmstat显示的iowait却非常高,就是下图中的wa选项。
iowait_oenhan
man vmstat手册如下解释:
wa: Time spent waiting for IO. Prior to Linux 2.5.41, included in idle.
CPU花费到IO等待上的时间,也就是说进程的io被CPU调度出去了,并没有进行立即执行,导致整个执行时间延长,程序性能降低。

那么wa是如何统计的呢?
vmstat是procps内实现的

在procps中,wa中通过getstat读取/proc/stat实现的。

proc/stat在内核中通过show_stat实现,统计cpustat.iowait获取最终结果:

而cpustat.iowait的值在account_system_time统计计算,通过统计rq->nr_iowait的值判断来递增。

附加一句:account_system_time可以用来具体统计更详细的CPU占用情况。

而控制的rq->nr_iowait的函数是io_schedule和io_schedule_timeout。

因为没有实际应用场景,针对调用代码做一下分析,具体的应用场景可以参考
查看调用代码如下:

io_schedule_oenhan

先看io_schedule函数,调用它的有sync_buffer,sync_io,dio_awit_one,direct_io_worker,get_request_wait等,只要你有对磁盘的写入操作,就会调用io_schedule,尤其以直接写入(DIO)最明显,每次写入都会调用。普通写入也只是积攒到buffer里面,统一刷新buffer的时候才会调用一次io_schedule。即使没有主动的写入IO,也有可能产生iowait,在sync_page函数中,当缓存和硬盘数据进行同步的时候,就会被调用,比如常用的mlock锁内存时就会__lock_page触发缓存同步,一样会增加iowait,一些读硬盘也会触发。

io_schedule_timeout_oenhan

虽然io_schedule调用的非常多,但真正的大杀器还是io_schedule_timeout,io_schedule由内核调用,整个调度时间还是比较短的,io_schedule_timeout则基本都是指定了HZ/10的时间段。如balance_dirty_pages中每次写入文件都会对脏页进行平衡处理,wb_kupdate定时器般进行缓存刷新,try_to_free_pages则在释放内存时刷缓存时使用,虽然不是每次都使用io_schedule_timeout,但综合各个的判断条件看,当内存中的缓存足够多的时候,会极大触发io_schedule_timeout,水线一般是dirty_background_ratio和dirty_ratio

如上所分析的,避免iowait需要注意的有:

1.高性能要求的进程最好在内存中一次读完所有数据,全部mlock住,不需要后面再读磁盘,

2.不需要写或者刷新磁盘(一般搞不定,就让单独的进程专门干这个活)。

3.控制整个缓存的使用情况,但从工程上不容易处理,虚拟化估计更有效,相对与系统虚拟化(KVM),进程虚拟化(cgroup)应该更简单有效。


iowait的形成原因和内核分析来自于OenHan

链接为:http://oenhan.com/iowait-wa-vmstat

发表评论