关于磁盘IO的一点东东

前天，发现新上的服务暴露了一个问题，有经常一阵阵的Connection reset by peer， 客户端超时断开，究竟是什么原因引起的呢？非常费解。

昨天做了一个timetrack，去跟踪每个有可能耗时的关键调用，观察到有时候调用存储组件(一个自己实现的日志流水存储组件)的读数据接口偶尔会需要耗时1~3秒，最夸张是有到6秒，(这些时间是相对时间，并非cpu占用时间)， 查看机器负载 loading 在正常范围。 由于是日志流水存储，所以所有的写操作都是append，下意识一直在怀疑是操作系统间歇的将buffer/cache中的数据回写磁盘，导致瞬间磁盘超负荷工作，导致这瞬间的所有IO被吊住，同时吊住后面的一些请求。

导致批量请求被“延迟”。

 

虽然怀疑是非常有可能的，但毕竟是下意识，必需找到一些数据才支撑自己的猜想。

 

 

 

1 vmstat 来观察：

 

使用vmstat, 发现 bo 有规律的 突升， 接着iowait变高到90左右，被block的进程数从几个变到90或上百，持续时间约2秒后回复正常，bo也降到正常值。

 

2 iostat 来观察：

使用iostat -tdx 1去观察每个盘的具体工作状况。重点关注几个参数：

 

w/s:   每秒写的请求

avgqu-sz: 平均I/O队列长度

await: 平均每次设备I/O操作的等待时间 (毫秒)。

svgtm:平均每次设备I/O操作的服务时间 (毫秒)。

%util:一秒中有百分之多少的时间用于 I/O 操作。

 

观察到 w/s ， avgqu-sz， await, svgtm %util 都突升。然后 又恢复正常水平。

 

以上这些参数，可以看出， 存在瞬间的写磁盘操作，导致磁盘超负荷， avgqu-sz的值很大，说明还有大部分I/O的请求都等待。

证明是这种偶发的写盘，导致突然性能低下。

 

分析：

 

追加写日志存储模型，就是想merge尽量多的写，然后一次性flush到磁盘上，提高磁盘写性能。但是，假设将10秒的量压到一瞬间去做，这瞬间磁盘全部用于flush， 那这瞬间的读，写肯定会被吊住。

 

我们还是想merge写操作，但是不需要merge这么久，我们需要的是均摊开销，将每秒的写操作merge，应该就可以解决这个问题。

 

于是：

调整操作系统 将buffer cache 回写到磁盘的一些参数， 让其回写更频繁一点。请教了相关的同事，P总给予指点，然后在zero同学的协助下，调整几个系统参数，通过几次，发现去掉预测的效果。Connection reset by peer的量降了下来。这也标志着服务质量有了质的改变，多了一个重要的监控指标。

 

ps: 主要调整的pdflush进程的一些参数， sysctl -a|grep vm，可以看到相关参数。

具体如何调整，就需要根据不同的场景做设置。具体参数可以参考：

http://www.pgsqldb.org/mwiki/index.php/Linux%E5%86%85%E6%A0%B8%E5%8F%82%E6%95%B0

 

评论

1 楼 lifc 2010-08-09  

感觉vm.dirty_*可能比较关键，但个人以为这类需求考虑用Circular buffer推送给独立线程去异步提交或许更合适，因为直接调整vm回写门限还会影响到其他方面（比如回写频率提高后磁头调度效果变差，长期运转噪声和发热量会有少许提高）。