HDD 正常运行，但 SMART 表示一切正常

Question

HDD 正常运行，但 SMART 表示一切正常

pan*_*a82 5 linux performance hard-drive smart

在我开始之前，快速免责声明。我基本上是一个因环境而被迫担任系统管理员角色的开发人员，所以如果我说一些愚蠢的话或看起来我不知道自己在做什么，我会提前道歉。

因此，我们的主服务器上的硬盘之一出现了问题。/dev/sda有两个分区，一个挂载为/，另一个用作 PostgreSQL 数据驱动器 ( /dev/sda2)。

$ df -h
Filesystem                                              Size  Used Avail Use% Mounted on
rootfs                                                   92G   13G   75G  14% /
udev                                                     10M     0   10M   0% /dev
tmpfs                                                   1.6G   12M  1.6G   1% /run
/dev/disk/by-uuid/8ffca87a-ffe4-4c39-ab30-352b61f039f8   92G   13G   75G  14% /
tmpfs                                                   5.0M     0  5.0M   0% /run/lock
tmpfs                                                   3.2G     0  3.2G   0% /run/shm
/dev/sda2                                               826G   66G  719G   9% /var/lib/data/vol1
/dev/sdb1                                               917G   75G  797G   9% /var/lib/data/vol2

Run Code Online (Sandbox Code Playgroud)

（/dev/sda1 出于某种原因使用其 UUID 挂载）

最近，它开始经历 100% IO R/W 的间隔，在此期间系统实际上被阻塞并且无法执行最简单的任务。

dmesg 的简短摘录：

[6554534.743764] INFO: task /usr/bin/monito:29408 blocked for more than 120 seconds.
[6554534.743828] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[6554534.743889] /usr/bin/monito D ffff88041fcd3780     0 29408      1 0x00000000
[6554534.743891]  ffff880101906780 0000000000000082 ffff880100000000 ffff88040f2c0100
[6554534.743893]  0000000000013780 ffff880187b45fd8 ffff880187b45fd8 ffff880101906780
[6554534.743895]  0000000000000246 000000018134fb39 ffff88041ffc8328 ffff88039bac2dd8
[6554534.743896] Call Trace:
[6554534.743899]  [<ffffffffa019e660>] ? do_get_write_access+0x1ad/0x36a [jbd2]
...

Run Code Online (Sandbox Code Playgroud)

我们知道这是由 PostgreSQL 查询触发的。这是发生这种情况时的 iotop 输出：

22609 be/4 postgres  441.12 K/s    0.00 B/s  0.00 % 98.46 % postgres: db_name~a_1 127.0.0.1(33183) SELECT
24359 be/4 postgres  988.02 K/s    0.00 B/s  0.00 % 98.22 % postgres: db_name~a_1 127.0.0.1(34194) SELECT

Run Code Online (Sandbox Code Playgroud)

您可能会想：“伙计，只需优化您的数据库。其中的奥秘在哪里？” 但是，请考虑 3 件事：

还有一个相同应用程序的另一个实例/dev/sdb，在类似的负载下运行相同的数据库架构。那里的 I/O 压力是正常的，很少超过 10-20%。
查看该列表中两个 PostgreSQL 进程的总吞吐量。它几乎不超过 1MB/s。对于数据库进程来说，这似乎太低了（应该优化为尽可能连续）。
无论 HDD 上的负载如何，它都不应该像这里那样完全阻塞，以至于产生内核错误并且只需ls一分钟即可完成。

我从这一切中得出的结论是，这/dev/sda是失败的，需要更换。这就是问题所在。在联系主机公司之前，我需要提供一些证明硬盘驱动器确实出现故障的证据。然而...

smartctl /dev/sda --all
smartctl 5.41 2011-06-09 r3365 [x86_64-linux-3.2.0-4-amd64] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF INFORMATION SECTION ===
Device Model:     WDC WD1003FBYZ-010FB0
...
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
...
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   200   200   051    Pre-fail  Always       -       0
  3 Spin_Up_Time            0x0027   100   253   021    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       2
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   100   253   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   098   098   000    Old_age   Always       -       2114
 10 Spin_Retry_Count        0x0032   100   253   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   253   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       2
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       2
193 Load_Cycle_Count        0x0032   200   200   000    Old_age   Always       -       9
194 Temperature_Celsius     0x0022   112   109   000    Old_age   Always       -       35
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   100   253   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   200   200   000    Old_age   Offline      -       0

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed without error       00%      2108         -

...

Run Code Online (Sandbox Code Playgroud)

（截断的输出，如果我删减太多，请给我评论）

如您所见，smartctl 表示一切正常。我什至做了一个完整的测试，没有发现错误。

所以我在这里不知所措。一切都指向出现故障的硬盘驱动器，但 SMART 监控未检测到任何内容。

我的问题：

我的诊断正确吗？驱动真的坏了吗？
如果是，我如何获得关于此的报告，我可以向托管公司展示以便他们同意更换它？
如果不是，下一个最有可能的罪魁祸首是什么？

更新 1

按照巴鲁克的建议，我执行了discscan。不幸的是，它没有发现我可以指出的任何内容。

diskscan /dev/sda
diskscan version HEAD

I: Validating path /dev/sda
I: Opened disk /dev/sda sector size 512 num bytes 1000204885504
I: Scanning disk /dev/sda in 65536 byte steps
I: Scan started at: Sun Aug 31 04:21:33 2014

Access time histogram:
       1: 14138808
      10: 923503
     100: 183268
     500: 15944
    1000: 436
    2000: 1
    3000: 0
    4000: 0
    5000: 0
    6000: 0
    7000: 0
    8000: 0
    9000: 0
   10000: 0
   15000: 0
   20000: 0
   25000: 0
   30000: 0
above that: 0
 1290 |                                                                       
      |                                                                       
      |                              ^                                        
      |                                                                       
      |                                                                       
 1075 |                                                                       
      |                                                                       
      |                          ^                                            
      |                                                                       
      |                                                                       
  860 |                                ^                                      
      |                                           ^               ^           
      |                                                                       
      |                           ^ ^           ^                          ^ ^
      |                  ^              ^^   ^     ^                          
  645 |                   ^^       ^  ^   ^^^ ^  ^    ^ ^^^^^       ^^      ^ 
      |        ^       ^        ^                            ^   ^ ^  ^^^ ^   
      | ^ ^       ^         ^                  ^       ^       ^^             
      |    ^                 ^                      ^         ^               
      |         ^     ^                              ^                   ^    
  430 |  ^  ^^^  ^ ^ ^                                                        
      |                                                                       
      |             ^   ^     ^^                                              
      |                                                                       
      |                                                                       
  215 |                                                                       
      |                                                                       
      |                                                                       
      | **********************************************************************
      | ______________________________________________________________________
      +-----------------------------------------------------------------------
Conclusion: passed
I: Scan ended at: Sun Aug 31 09:22:34 2014

I: Scan took 18061 second
I: Closed disk /dev/sda

Run Code Online (Sandbox Code Playgroud)

我还更新了我的部分备份，并准备在继续之前进行完整备份。

下一步：

我安装了 iosnoop 脚本（由 Baruch 推荐）。我可以让它收集延迟，但我不知道如何让它为托管公司生成任何可操作的信息。

巴鲁克的第三个建议在我的脑海中。如果我发现了什么，我会更多地研究它并更新。

如果到明天我还没有弄清楚任何事情，我会建议无论如何购买另一个磁盘并将 sda 转移到那里。然后我们将知道是否存在磁盘问题或其他问题，并从那里继续。

更新 2

执行smartctl -x。没什么可看的，但这里有一个带有完整结果的pastebin。

按照 Baruch 的说明启用详细的 scsi 日志记录。我的 /var/log/messages 中有很多这样的东西：

Aug 31 15:28:07 swfemail kernel: [7539683.491379] sd 0:0:0:0: [sda] Send: 
Aug 31 15:28:07 swfemail kernel: [7539683.491382] sd 0:0:0:0: [sda] CDB: Write(10): 2a 00 01 3f ce 80 00 00 10 00
Aug 31 15:28:07 swfemail kernel: [7539683.491526] sd 0:0:0:0: [sda] Send: 
Aug 31 15:28:07 swfemail kernel: [7539683.491528] sd 0:0:0:0: [sda] CDB: Synchronize Cache(10): 35 00 00 00 00 00 00 00 00 00
Aug 31 15:28:08 swfemail kernel: [7539684.411573] sd 0:0:0:0: [sda] Send: 
Aug 31 15:28:08 swfemail kernel: [7539684.411576] sd 0:0:0:0: [sda] CDB: Write(10): 2a 00 01 b6 da d0 00 00 08 00
Aug 31 15:28:08 swfemail kernel: [7539684.411597] sd 0:0:0:0: [sda] Send: 
Aug 31 15:28:08 swfemail kernel: [7539684.411598] sd 0:0:0:0: [sda] CDB: Write(10): 2a 00 01 b6 ba d0 00 00 08 00
Aug 31 15:28:08 swfemail kernel: [7539684.411639] sd 0:0:0:0: [sda] Send: 
Aug 31 15:28:08 swfemail kernel: [7539684.411639] sd 0:0:0:0: [sda] CDB: Write(10): 2a 00 05 c6 18 88 00 00 a8 00
Aug 31 15:28:08 swfemail kernel: [7539684.412056] sd 0:0:0:0: [sda] Send: 
Aug 31 15:28:08 swfemail kernel: [7539684.412057] sd 0:0:0:0: [sda] CDB: Synchronize Cache(10): 35 00 00 00 00 00 00 00 00 00

Run Code Online (Sandbox Code Playgroud)

到目前为止，没有什么特别有用的东西，但是磁盘已经进入了“安静”阶段。一旦它再次开始阻塞，我将尝试捕获输出。

迟到我想检查旧的内核错误消息。没有什么会作为直接错误弹出。只是一堆超时警告。

更新 3

尝试在 100% 压力时间窗口内读取 scsi 日志。没有错误或超时条目:-(

我们添加了另一个硬盘。目前我正在克隆它dd if=/dev/sda of=/dev/sdc bs=32M（稍后我将在离线时使用 rsync 进行另一次传递）。我希望这能在一天结束时完成。

几天后我会再次更新结果。

更新 4

由于我们托管公司的问题，我们无法完全切换到新磁盘。在问题解决之前，我们妥协了，只将数据库移动到新磁盘。这是当前布局（仅限相关设备）：

/dev/sdc1                                       92G   23G   65G  26% /
/dev/sdb1                                      917G  170G  701G  20% /var/lib/data/vol2
/dev/sda2                                      826G   71G  714G   9% /var/lib/data/vol1

Run Code Online (Sandbox Code Playgroud)

/dev/sdc是（可能）坏磁盘。/dev/sda是现在拥有数据库的新磁盘。

下一步是监控情况并查看 100% 使用率爆发是否恢复。我会在几天内更新（并希望发布已接受的答案）。

Answer 1

Bar*_*ven 5

您很可能遇到了磁盘问题。磁盘出现故障，一种相当常见的故障方法是由于磁盘上某些问题区域的重试次数增加而具有更高的延迟，这些区域在命中时会导致其他 IO 的连锁反应等待它们，如果有多个 IO到受影响的区域，您会看到这样一个问题，因为会有多个 IO 阻塞超过 10 秒。

我可以推荐使用diskscan测试磁盘，它会显示整个磁盘的延迟图。它可以在只读模式下工作，因此它根本没有破坏性。您也可以要求它修复可读但速度很慢的区域，但首先测试磁盘以查看其行为。

问题可能是间歇性的，因此磁盘扫描不会注意到。您可以运行iosnoop来收集所有 IO 及其延迟的历史记录。该脚本增加了一些开销，但效果很好。如果问题很少发生，它可能需要一些脚本来进行更长的日志记录会话。

您可以提高 scsi 子系统日志记录级别以尝试从内核中获取更多信息，如果您使用 LSI SAS HBA 访问磁盘，您还可以提高 mpt2sas 驱动程序的日志记录级别以从中获取更多信息。两者都可以帮助查看内核中是否存在超时和中止。检查是否可以在内核中看到有关超时和中止的日志消息，它们可以作为另一个线索。

编辑1：

要启用 SCSI 调试日志，您可以使用以下命令：echo 9411 > /proc/sys/dev/scsi/logging_level您可能需要为 sys 文件使用不同的位置。

还尝试使用 -x 选项运行 smartctl，它会显示一些最后的错误（如果有的话）。

归档时间：	11 年，3 月前
查看次数：	946 次
最近记录：	11 年，3 月前