注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

永福的技术博客

Linux运维

 
 
 

日志

 
 

关于磁盘IO的一点东东【转】  

2011-07-25 15:25:06|  分类: CentOS |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

前天,发现新上的服务暴露了一个问题,有经常一阵阵的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

  评论这张
 
阅读(427)| 评论(0)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017