☰

奇怪的反复过度 I/O 等待

tag-icon • tag-icon linux cache iowait
奇怪的反复过度 I/O 等待

我很清楚，I/O 等待已在此网站上讨论过多次，但其他所有主题似乎都涵盖了持续的I/O 延迟，虽然我们需要在服务器上解决的 I/O 问题以不规则（短）间隔发生，但始终存在大量峰值，每次等待时间高达 20k 毫秒，服务时间为 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

让我为您提供有关硬件的更多信息。这是一台 Dell 1950 III 机器，操作系统为 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 RAM 中的约 0.8 GB，平均 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, RAID-1, 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 图 1，24 分钟间隔：http://imageshack.us/photo/my-images/600/yqm3.png/

iostat 图 2，120 分钟间隔：http://imageshack.us/photo/my-images/407/griw.png/

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

echo 3 > /proc/sys/vm/drop_caches

紧接着，I/O 等待和服务时间几乎飙升，机器上的一切都感觉像慢动作一样。在接下来的几个小时里，延迟恢复了，一切都和以前一样——在短时间内出现小到中等的滞后，时间间隔不可预测。

现在我的问题是：有人知道是什么原因导致了这种恼人的行为吗？这是磁盘阵列或 RAID 控制器即将损坏的第一个迹象，还是可以通过重新启动轻松修复的问题？（不过，目前我们非常不愿意这样做，因为我们担心磁盘可能无法再次恢复。）

任何帮助是极大的赞赏。

提前谢谢你，克里斯。

编辑后补充：我们确实看到 top 中有一两个进程进入“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]

答案1

（例如，我假设您的磁盘直接连接到服务器，而不是通过 NFS。）

重要的是你的韓國（iostat输出中）是极其高，表明 RAID 或磁盘存在硬件问题。斯维特对于普通磁盘来说，大约为 4 (ms)。可能更少，但不会太高。

不幸的是，smartctl您的情况的输出不具参考价值。它已更正错误，但这可能是正常的。长时间测试似乎已完成，但仍然没有定论。ST3500620SS 似乎是老式的服务器/RAID 类型磁盘，它应该对读取错误做出快速响应（与台式机/非 RAID 磁盘不同），因此这可能是比坏扇区更复杂的硬件问题。尝试在 RAID 统计数据中查找异常情况（如高错误率）：http://hwraid.le-vert.net/wiki/LSIMegaRAIDSAS

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

更新：

斯维特是更重要的因素，因为高实用性%只是结果的韓國异常高。

我看到过类似的问题桌面磁盘已安装到承诺RAID。台式机磁盘设计为通过多次长时间重试来尝试修复读取错误，这会导致延迟（这些读取错误可能是由于其他因素造成的，例如振动，在服务器机房中比在台式机中强得多）。与此不同，设计用于 RAID 的磁盘只会快速向 RAID 控制器报告任何错误，后者可以通过 RAID 冗余纠正这些错误。此外，服务器磁盘可以设计为在机械上更耐持续强烈振动。有一种普遍的误解认为服务器磁盘与台式机相同，只是价格更贵，这是错误的，它们是实际上有所不同。

问：啊，我想问的是：如果是硬件问题，您不认为问题应该持续可见，而不是在一段时间内消失吗？您对这种影响有什么解释吗？

A：

  1. 问题可能一直存在，但它成为显仅在高负载下。
  2. 一天中的不同时间，振动水平可能不同（例如，取决于附近的服务器在做什么）。如果您的问题是磁盘受到振动的影响，那么它肯定会消失并重新出现。当我遇到“桌面磁盘”问题时，我看到了类似的行为。（当然，您的磁盘是服务器磁盘，建议用于 RAID，因此这不是完全相同的问题。但它可能是相似的。）

答案2

我遇到了非常类似的问题。IBM ServeRaid M5110（更名为 LSI 9265-8i）和 CentOS 6.x

第一个 VD 是 4 个 IBM 品牌日立驱动器的 RAID0。

然后我们购买了三星 PM853T SSD，并将它们安装在另外 4 个驱动器中，并创建了另一个 RAID0。当我们将工作负载从磁盘切换到 SSD 时，每隔 1 小时 IO 就会猛增，所有操作都会停止。负载会从正常的约 2 上升到超过 80。几十秒后，一切都会平静下来，应用程序将继续运行。

这种情况在盘片上从来没有发生过。

所以，我的第一印象是 LSI 和三星之间存在某种不兼容性。经过几天的思考和调试，我发现 MegaCli64 是罪魁祸首。我们通过 Zabbix 运行它来监控驱动器的健康状况，但在扫描控制器时，MegaCli 会在 SSD 处停止等待，每个 SSD 需要几十秒，乘以 4，几乎需要两分钟。这会使所有 I/O 降至零，并使 iowait 和负载飙升。

解决方案是找到不会引起问题的 MegaCli 版本。我们从 IBM 网站下载了该版本。

答案3

我们遇到了类似的问题，结果发现是由思科 UCSC-RAID12GP-4G卡。下面是我们如何解决问题。

  1. 找出 Linux 发现的哪个磁盘的 IO 卡在了飞行中。我们使用了这个命令：
watch -n .1 "tail /sys/block/{nvme,sda}*/stat | awk '{print \$9}'"

NVMe 的飞行中 IO 几乎始终为零。但是，第三项显示/dev/sda飞行中值相当稳定，很少变化（只会增加），因此我们知道这是 megaraid 控制器导出的磁盘的问题。

  1. 在系统的每个磁盘上运行 smartctl：
smartctl --scan | cut -f1 -d'#' | while read a; do echo ======= $a ; smartctl -a $a; done 2>&1|less

我们发现了一个类似这样的：

======= /dev/bus/1 -d megaraid,36
smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.15.0-7.86.6.1.el9uek.x86_64-TEST+] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Vendor:               HGST
Product:              HUH721010AL4200
Revision:             A21D
Compliance:           SPC-4
User Capacity:        10,000,831,348,736 bytes [10.0 TB]
Logical block size:   4096 bytes
LU is fully provisioned
Rotation Rate:        7200 rpm
Form Factor:          3.5 inches
Logical Unit id:      0x5000cca266873ed8
Serial number:        7JJDBTEG
Device type:          disk
Transport protocol:   SAS (SPL-3)
Local Time is:        Sat Sep 30 15:52:50 2023 PDT
SMART support is:     Available - device has SMART capability.
SMART support is:     Enabled
Temperature Warning:  Enabled

=== START OF READ SMART DATA SECTION ===
SMART Health Status: FIRMWARE IMPENDING FAILURE DATA ERROR RATE TOO HIGH [asc=5d, ascq=62]

因此，我们记下了磁盘序列号 (7JJDBTEG)，然后使用以下代码登录 MegaRAID 控制台：二甲基砜并将驱动器标记为脱机。IO 立即开始流动，系统无需重启即可恢复：

MSM 还显示驱动器上有错误：

MSM 磁盘错误

相关内容