linux – 奇怪的经常性过度I / O等待

分类：Linux作者：编程之家用户
我非常清楚I / O等待已在本网站上多次讨论,但所有其他主题似乎都涵盖了持续的I / O延迟,而我们需要在服务器上解决的I / O问题是不规则的(短暂的) )间隔,但始终存在高达20k ms的大量尖峰 – 等待和2秒的服务时间.受影响的磁盘是/ dev / sdb(Seagate Barracuda,详见下文).

典型的iostat -x输出有时看起来像这样,这是一个极端的样本,但绝不是罕见的：

iostat (Oct 6,2013)
  tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util
 0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
 0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
16.00      0.00    156.00      9.75     21.89    288.12     36.00     57.60
 5.50      0.00     44.00      8.00     48.79   2194.18    181.82    100.00
 2.00      0.00     16.00      8.00     46.49   3397.00    500.00    100.00
 4.50      0.00     40.00      8.89     43.73   5581.78    222.22    100.00
14.50      0.00    148.00     10.21     13.76   5909.24     68.97    100.00
 1.50      0.00     12.00      8.00      8.57   7150.67    666.67    100.00
 0.50      0.00      4.00      8.00      6.31  10168.00   2000.00    100.00
 2.00      0.00     16.00      8.00      5.27  11001.00    500.00    100.00
 0.50      0.00      4.00      8.00      2.96  17080.00   2000.00    100.00
34.00      0.00   1324.00      9.88      1.32    137.84      4.45     59.60
 0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
22.00     44.00    204.00     11.27      0.01      0.27      0.27      0.60

让我为您提供有关硬件的更多信息.这是戴尔1950年代的盒子,Debian作为操作系统,其中uname -a报告如下：

Linux xx 2.6.32-5-amd64 #1 SMP Fri Feb 15 15:39:52 UTC 2013 x86_64 GNU/Linux

该机器是一个专用服务器,可托管在线游戏,无需运行任何数据库或I / O繁重的应用程序.核心应用程序占用8 GB内存中的大约0.8,并且平均CPU负载相对较低.然而,游戏本身对I / O延迟反应相当敏感,因此我们的玩家会遇到大量的游戏延迟,我们希望尽快解决.

iostat:
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1.77    0.01    1.05    1.59    0.00   95.58

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sdb              13.16        25.42       135.12  504701011 2682640656
sda               1.52         0.74        20.63   14644533  409684488

正常运行时间是：

19:26:26 up 229 days,17:26,4 users,load average: 0.36,0.37,0.32

硬盘控制器：

01:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS 1078 (rev 04)

硬碟：

Array 1,RAID-1,2x Seagate Cheetah 15K.5 73 GB SAS
Array 2,2x Seagate ST3500620SS Barracuda ES.2 500GB 16MB 7200RPM SAS

来自df的分区信息：

Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sdb1            480191156  30715200 425083668   7% /home
/dev/sda2              7692908    437436   6864692   6% /
/dev/sda5             15377820   1398916  13197748  10% /usr
/dev/sda6             39159724  19158340  18012140  52% /var

使用iostat -dx sdb 1生成的更多数据样本(2013年10月11日)

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sdb               0.00    15.00    0.00   70.00     0.00   656.00     9.37     4.50    1.83   4.80  33.60
sdb               0.00     0.00    0.00    2.00     0.00    16.00     8.00    12.00  836.00 500.00 100.00
sdb               0.00     0.00    0.00    3.00     0.00    32.00    10.67     9.96 1990.67 333.33 100.00
sdb               0.00     0.00    0.00    4.00     0.00    40.00    10.00     6.96 3075.00 250.00 100.00
sdb               0.00     0.00    0.00    0.00     0.00     0.00     0.00     4.00    0.00   0.00 100.00
sdb               0.00     0.00    0.00    2.00     0.00    16.00     8.00     2.62 4648.00 500.00 100.00
sdb               0.00     0.00    0.00    0.00     0.00     0.00     0.00     2.00    0.00   0.00 100.00
sdb               0.00     0.00    0.00    1.00     0.00    16.00    16.00     1.69 7024.00 1000.00 100.00
sdb               0.00    74.00    0.00  124.00     0.00  1584.00    12.77     1.09   67.94   6.94  86.00

使用rrdtool生成的特征图表可以在这里找到：

iostat plot 1,24 min interval：http://imageshack.us/photo/my-images/600/yqm3.png/

iostat plot 2,120 min interval：http://imageshack.us/photo/my-images/407/griw.png/

由于我们有一个相当大的5.5 GB的缓存,我们认为测试I / O等待峰值是否可能是由缓存未命中事件引起可能是一个好主意.因此,我们进行了同步,然后刷新缓存和缓冲区：

echo 3 > /proc/sys/vm/drop_caches

然后直接I / O等待和服务时间几乎通过屋顶,机器上的所有东西都感觉像是慢动作.在接下来的几个小时内,延迟恢复,一切都像以前一样 – 在短暂的,不可预测的时间间隔内发生中小滞后.

现在我的问题是：有没有人知道什么可能导致这种令人讨厌的行为？它是磁盘阵列或raid控制器死亡的第一个迹象,还是可以通过重新启动轻松修复的东西？ (目前我们非常不愿意这样做,因为我们担心磁盘可能不会再次恢复.)

任何帮助是极大的赞赏.

提前致谢,
克里斯.

编辑添加：我们确实看到一个或两个进程在顶部进入’D’状态,其中一个似乎是相当频繁的kjournald.但是,如果我没有弄错的话,这并不表示导致延迟的过程,而是那些受其影响的过程 – 如果我错了,请纠正我.有关不间断睡眠过程的信息是否有助于我们以任何方式解决问题？

@Andy Shinn请求smartctl数据,这里是：

smartctl -a -d megaraid,2 / dev / sdb产生：

smartctl 5.40 2010-07-12 r3124 [x86_64-unknown-linux-gnu] (local build)
Copyright (C) 2002-10 by Bruce Allen,http://smartmontools.sourceforge.net

Device: SEAGATE  ST3500620SS      Version: MS05
Serial number:
Device type: disk
Transport protocol: SAS
Local Time is: Mon Oct 14 20:37:13 2013 CEST
Device supports SMART and is Enabled
Temperature Warning Disabled or Not Supported
SMART Health Status: OK

Current Drive Temperature:     20 C
Drive Trip Temperature:        68 C
Elements in grown defect list: 0
Vendor (Seagate) cache information
  Blocks sent to initiator = 1236631092
  Blocks received from initiator = 1097862364
  Blocks read from cache and sent to initiator = 1383620256
  Number of read and write commands whose size <= segment size = 531295338
  Number of read and write commands whose size > segment size = 51986460
Vendor (Seagate/Hitachi) factory information
  number of hours powered up = 36556.93
  number of minutes until next internal SMART test = 32

Error counter log:
           Errors Corrected by           Total   Correction     Gigabytes    Total
               ECC          rereads/    errors   algorithm      processed    uncorrected
           fast | delayed   rewrites  corrected  invocations   [10^9 bytes]  errors
read:   509271032       47         0  509271079   509271079      20981.423           0
write:         0        0         0         0          0       5022.039           0
verify: 1870931090      196         0  1870931286   1870931286     100558.708           0

Non-medium error count:        0

SMART Self-test log
Num  Test              Status                 segment  LifeTime  LBA_first_err [SK ASC ASQ]
     Description                              number   (hours)
# 1  Background short  Completed                  16   36538                 - [-   -    -]
# 2  Background short  Completed                  16   36514                 - [-   -    -]
# 3  Background short  Completed                  16   36490                 - [-   -    -]
# 4  Background short  Completed                  16   36466                 - [-   -    -]
# 5  Background short  Completed                  16   36442                 - [-   -    -]
# 6  Background long   Completed                  16   36420                 - [-   -    -]
# 7  Background short  Completed                  16   36394                 - [-   -    -]
# 8  Background short  Completed                  16   36370                 - [-   -    -]
# 9  Background long   Completed                  16   36364                 - [-   -    -]
#10  Background short  Completed                  16   36361                 - [-   -    -]
#11  Background long   Completed                  16       2                 - [-   -    -]
#12  Background short  Completed                  16       0                 - [-   -    -]

Long (extended) Self Test duration: 6798 seconds [113.3 minutes]

smartctl -a -d megaraid,3 / dev / sdb产量：

smartctl 5.40 2010-07-12 r3124 [x86_64-unknown-linux-gnu] (local build)
Copyright (C) 2002-10 by Bruce Allen,http://smartmontools.sourceforge.net

Device: SEAGATE  ST3500620SS      Version: MS05
Serial number:
Device type: disk
Transport protocol: SAS
Local Time is: Mon Oct 14 20:37:26 2013 CEST
Device supports SMART and is Enabled
Temperature Warning Disabled or Not Supported
SMART Health Status: OK

Current Drive Temperature:     19 C
Drive Trip Temperature:        68 C
Elements in grown defect list: 0
Vendor (Seagate) cache information
  Blocks sent to initiator = 288745640
  Blocks received from initiator = 1097848399
  Blocks read from cache and sent to initiator = 1304149705
  Number of read and write commands whose size <= segment size = 527414694
  Number of read and write commands whose size > segment size = 51986460
Vendor (Seagate/Hitachi) factory information
  number of hours powered up = 36596.83
  number of minutes until next internal SMART test = 28

Error counter log:
           Errors Corrected by           Total   Correction     Gigabytes    Total
               ECC          rereads/    errors   algorithm      processed    uncorrected
           fast | delayed   rewrites  corrected  invocations   [10^9 bytes]  errors
read:   610862490       44         0  610862534   610862534      20470.133           0
write:         0        0         0         0          0       5022.480           0
verify: 2861227413      203         0  2861227616   2861227616     100872.443           0

Non-medium error count:        1

SMART Self-test log
Num  Test              Status                 segment  LifeTime  LBA_first_err [SK ASC ASQ]
     Description                              number   (hours)
# 1  Background short  Completed                  16   36580                 - [-   -    -]
# 2  Background short  Completed                  16   36556                 - [-   -    -]
# 3  Background short  Completed                  16   36532                 - [-   -    -]
# 4  Background short  Completed                  16   36508                 - [-   -    -]
# 5  Background short  Completed                  16   36484                 - [-   -    -]
# 6  Background long   Completed                  16   36462                 - [-   -    -]
# 7  Background short  Completed                  16   36436                 - [-   -    -]
# 8  Background short  Completed                  16   36412                 - [-   -    -]
# 9  Background long   Completed                  16   36404                 - [-   -    -]
#10  Background short  Completed                  16   36401                 - [-   -    -]
#11  Background long   Completed                  16       2                 - [-   -    -]
#12  Background short  Completed                  16       0                 - [-   -    -]

Long (extended) Self Test duration: 6798 seconds [113.3 minutes]

解决方法

(我假设您的磁盘直接连接到服务器,而不是通过NFS连接.)

重要的是你的svctm(在iostat输出中)非常高,这表明RAID或磁盘存在硬件问题.普通磁盘的Svctm应该在4(ms)左右.可能会少,但不会太高.

不幸的是,在您的情况下,smartctl输出不提供信息.它纠正了错误,但这可能是正常的.长时间的测试似乎已经完成了,但这又是不确定的. ST3500620SS似乎是很好的旧服务器/ raid类型磁盘,它应该在读取错误时快速响应(与桌面/非raid磁盘不同),因此这可能是比坏扇区更复杂的硬件问题.尝试在RAID统计数据中找到不寻常的东西(如高错误率)：http://hwraid.le-vert.net/wiki/LSIMegaRAIDSAS

我的建议是磁盘更换应该是下一步.

更新：

Svctm是更重要的因素,因为高利用率只是svctm异常高的结果.

桌面磁盘安装到Promise RAID时,我发现了类似的问题.桌面磁盘设计用于尝试通过许多长时间重试来修复读取错误,这会导致延迟(这些读取错误可能是由于某些其他因素,例如振动,这在服务器机房比在桌面上强得多).与此不同的是,设计用于RAID的磁盘只会快速向RAID控制器报告任何错误,RAID控制器可以使用RAID reduncancy来纠正它们.此外,服务器磁盘可以设计为更加机械地抵抗持续的强烈振动.有一个常见的神话,即服务器磁盘与桌面相同只是更昂贵,这是错误的,它们实际上是不同的.

问：啊,我想问一下：如果这是一个硬件问题,你不觉得问题应该持续可见而且不会消失一段时间吗？你碰巧对这种效果有任何解释吗？

A：

>问题可能总是存在,但只有在高负荷时才会变得明显.>在一天中的不同时间,振动水平可能会有所不同(例如,取决于附近的服务器所做的事情).如果您的问题是磁盘受到振动影响,它肯定会消失并重新出现.当我遇到“桌面磁盘”问题时,我看到了类似的行为. (当然,你的磁盘是服务器磁盘,推荐用于RAID,所以它不是完全相同的问题.但它可能类似.)

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。

相关推荐

linux进程通信
linux常用进程通信方式包括管道（pipe）、有名管道（FIFO）、信号（signal）、消息队列、共享内存、信号量、套接字（socket)。管道用于具有亲缘关系的进程间通信,有名管道的每个管道具有名字,使没有亲缘关系的进程间也可以通信。信号是比较复杂的通信方式，用于通知接受进程有某种事件发生，除
Linux常用性能工具功能、用法及原理(一)
Linux性能观测工具按类别可分为系统级别和进程级别，系统级别对整个系统的性能做统计,而进程级别则具体到进程,为每个进程维护统计信息。&#xD;&#xA;&#xD;&#xA;按实现原理分,可分为基于计数器和跟踪以及剖析。含义如下:&#xD;&#xA;&#xD;&#xA;计数器:内核维护的统计数据，通常为无符号整型,用于对发生的事件计数,比如，网络包接收计数器,磁
curl命令详解
本文详细介绍了curl命令基础和高级用法，包括跳过https的证书验证，详细追踪整个交互过程,可用于调用网络后端接口，诊断http和https网络服务故障。
linux常用命令示例汇总
本文包含作者工作中常用到的一些命令,用于诊断网络、磁盘占满、fd泄漏等问题。命令包括ping、fping、tcpdump、lsof、netstat、/proc/$pid/fd、du、grep、traceroute、dig。
linux平均负载的理解及原因排查
linux的平均负载表示运行态和就绪态及不可中断状态(正在io)的进程数目,用uptime查看到负载很高，既有可能是CPU利用率高，也可能是大量在等待io的进程导致，用mpstat查看每个CPU的使用情况，查看CPU的使用率或者CPU花在等待io的时间，接着用pidstat定位具体的进程
CPU上下文切换
CPU上下文频繁切换会导致系统性能下降，切换分为进程切换、线程切换及中断切换，进程切换的开销较大，除了需要保存寄存器和程序计数器中的值还需保存全局变量、栈等到内存中，以便下次运行恢复，而同一进程中的线程切换开销会小很多，只需更新寄存器和线程独有的栈，共享资源如打开的文件、全局变量等无需切换，当硬件中
linux常用命令学习笔记
1.top命令 作用：该命令可以按CPU使用.内存使用和执行时间对任务进行排序，常用来监控系统中占用CPU或内存较高的程序及CPU和内存的负载。 默认视图： 当想看系统负载时，可观察汇总的%CPU中的us用户进程和sy系统进程是否占用CPU很高，相加接近100%就说明占用很高了，有些程序可能得不到及
【Linux】权限完结
文章浏览阅读1.8k次，点赞63次，收藏54次。Linux下的目录权限！！！粘滞位！！！超详解！！！
5、关于Qt的安装、Windows、Linux、MacBook
文章浏览阅读1.6k次，点赞44次，收藏38次。关于Qt的安装、Windows、Linux、MacBook_mack book 安装qt
Linux之shell脚本
本文介绍了使用shell脚本编写一个 Hello
【Linux】糟糕，是心动的感觉——与Linux的初次相遇
文章浏览阅读1.5k次，点赞37次，收藏43次。【Linux】初识Linux——了解操作系统的发展历史以及初次体验Linux编程环境
Linux超详细笔记
文章浏览阅读3k次，点赞34次，收藏156次。Linux超详细笔记，个人学习时很认真的记录的，觉得好的麻烦点个赞。
【Linux】 OpenSSH_9.3p1 升级到 OpenSSH_9.5p1（亲测无问题，建议收藏）
文章浏览阅读6.8k次，点赞109次，收藏114次。【Linux】 OpenSSH_9.3p1 升级到 OpenSSH_9.5p1（亲测无问题，建议收藏）_openssh_9.5p1
【Linux】线程概念和线程控制
文章浏览阅读3.5k次，点赞93次，收藏78次。初识Linux中的线程，理解线程的各种概念，理解进程地址空间中的页表转换，介绍pthread线程库并理解线程库！
UE Linux常见错误
文章浏览阅读863次。出现此问题为Linux文件权限问题，解决方案为回到引擎目录执行命令。输入用户密码后运行./UnrealEditor。_increasing per-process limit of core file size to infinity.
Linux shell操作.csv文件
文章浏览阅读2.9k次。使用文本编辑器：打开CSV文件，并使用文本编辑器（如Notepad++、Sublime Text、Visual Studio Code等）来查看文件的字符编码格式。通常在编辑器的底部状态栏或设置中可以找到当前编码的显示。请注意，上述方法并非绝对准确，特别是当文件没有明确的编码标识时。因此，如果你发现CSV文件在不同的工具或方法中显示不同的编码格式，可能需要进行进一步的分析和判断，或者尝试使用不同的编码转换方法。该命令将输出文件的MIME类型和编码信息。使用命令行工具：在命令行中，你可以使用。_shell读取csv文件逐行处理
linux升级gcc版本详细教程
本文介绍了如何在Linux系统中升级gcc版本，以便更好地支持C++11及以上版本的新特性。通过升级gcc，可以提升编译器的功能和性能，获得更好的开发体验。详细的步骤和方法请参考原文链接。
linux下的mosquitto服务安装及使用（避坑指南）
文章浏览阅读4.4k次，点赞6次，收藏19次。Mosquitto是一个开源的MQTT消息代理服务器。MQTT是一个轻量级的、基于发布/订阅模式的消息传输协议。 mosquitto的安装使用比较简单，可以方便的来进行一些测试。_linux mosquitto
Linux ~/.ssh目录详解和密钥对使用
文章浏览阅读7.2k次，点赞2次，收藏12次。Linux中，用于根目录下有一个.ssh目录，保存了ssh相关的key和一些记录文件。_~/.ssh/
安装和配置SNMP(windows10和Linux)--附SNMP客户端工具
文章浏览阅读4.5k次，点赞5次，收藏18次。首先需要安装 snmp ，使用下面的命令进行安装安装完毕之后，使用下面的命令查看是否安装成功当命令行显示如图即为安装成功。_snmp工具
pythonJavaScriptjavaHTMLPHPreactjsC#AndroidCSSNode.jssqlrpython-3.xMysqLjQueryc++pandasFlutterangularIOSdjangolinuxswifttypescript路由器JSON路由器设置无线路由器h3c华三华三路由器设置华三路由器电脑软件教程arraysdocker软件图文教程Cvue.jslaravelspring-boot