如何判断linux磁盘IO是否导致过多(> 1秒)的应用程序停顿

我有一个 Java应用程序执行大容量(数百MB)的连续输出(流纯文本)到大约12个文件ext3 SAN文件系统.有时,此应用程序一次暂停几秒钟.我怀疑与ext3 vsfs(Veritas Filesystem)功能相关的东西(和/或它与操作系统的交互方式)是罪魁祸首.

我可以采取哪些步骤来证实或反驳这一理论?我知道iostat和/ proc / diskstats作为起点.

修改标题不再强调日记并强调“摊位”

我做了一些谷歌搜索,发现至少有一篇文章似乎描述了我正在观察的行为:Solving the ext3 latency problem

附加信息

>红帽企业Linux服务器版本5.3(Tikanga)
>内核:2.6.18-194.32.1.el5
>主应用程序磁盘是光纤通道SAN:lspci | grep -i fiber>> 14:00.0光纤通道:Emulex Corporation Saturn-X:LightPulse光纤通道主机适配器(rev 03)
>装载信息:输入vxfs(rw,tmplog,largefiles,mincache = tmpcache,ioerror = mwdisable)0 0
> cat / sys / block / VxVM123456 / queue / scheduler>> noop expectedatory [截止日期] cfq

解决方法

我的猜测是,还有一些其他进程会占用磁盘I / O容量一段时间.如果你有一个足够的内核,iotop可以帮助你找到它.

如果是这种情况,则不是关于文件系统,更不用说日志了.负责在冲突的应用程序之间进行仲裁的是I / O调度程序.一个简单的测试:检查当前的调度程序并尝试不同的调度程序.它可以在运行中完成,无需重新启动.例如,在我的桌面上检查第一个磁盘(/ dev / sda):

cat /sys/block/sda/queue/scheduler
=>  noop deadline [cfq]

表明它使用的是CFQ,这对于台式机来说是一个不错的选择,但对服务器来说并不是很好.更好地设定’截止日期’:

echo 'deadline' > /sys/block/sda/queue/scheduler
cat /sys/block/sda/queue/scheduler
=>  noop [deadline] cfq

并等待几个小时,看看它是否有所改善.如果是这样,请在启动脚本中永久设置(取决于分发)

相关文章

linux常用进程通信方式包括管道(pipe)、有名管道(FIFO)、...
Linux性能观测工具按类别可分为系统级别和进程级别,系统级别...
本文详细介绍了curl命令基础和高级用法,包括跳过https的证书...
本文包含作者工作中常用到的一些命令,用于诊断网络、磁盘占满...
linux的平均负载表示运行态和就绪态及不可中断状态(正在io)的...
CPU上下文频繁切换会导致系统性能下降,切换分为进程切换、线...