在我开始之前，快速的声明。 我基本上是一个开发人员被情况下强迫进入系统pipe理员angular色，所以我提前道歉，如果我说一些愚蠢的或似乎我不知道我在做什么。
所以，我们的主服务器上的HDD-s有问题。 /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
（由于某种原因，使用其UUID挂载/ dev / sda1）
最近，它开始经历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] ...
我们知道这是由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
你可能会想：“只要优化你的数据库，伙计，这个秘密在哪里？ 但是，考虑三件事情：
还有另一个同样的应用程序的实例，在类似的负载下在/dev/sdb上运行相同的数据库模式。 I / O压力正常，很less超过10-20％。
查看该列表中两个PostgreSQL进程的总吞吐量。 它几乎没有通过1MB /秒。 对于数据库进程来说这似乎太低了（应该尽可能按顺序进行优化）。
无论硬盘上的负载如何，它都不应该完全按照它在这里所做的那样完全阻塞，直到产生内核错误和简单的ls花费一分钟才能完成。
我的结论是， /dev/sda失败，需要更换。 这就是问题所在。 在联系主机公司之前，我需要提供一些证据certificate硬盘是真正失效的。 然而…
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 - ...
（截断输出，如果我切出太多，请给我评论）
正如你所看到的，smartctl说一切正常。 我甚至做了一个完整的testing，没有发现错误。
所以我在这里亏本 一切指向一个失败的硬盘驱动器，但SMART监控不检测任何东西。
我的问题：
更新1
根据Baruch的build议，我执行了盘扫。 不幸的是，它没有发现我可以指出的东西。
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
我还更新了我的部分备份，并准备完成备份，然后再继续。
下一步：
我安装了iosnoop脚本（由Baruchbuild议）。 我可以得到它来收集延迟，但我无法弄清楚如何让它产生任何东西，这将是托pipe公司可操作的信息。
巴鲁克的第三个build议是在我的头上方。 如果我找出一些东西，我会更多地考虑它，并更新它。
如果明天我没有弄清楚什么，我会build议你再购买一张磁盘，然后在那里转移sda。 然后我们会知道是否有磁盘问题或其他问题，并从那里继续。
更新2
执行smartctl -x 。 没什么可看的，但是这里有一个完整的结果的pastebin 。
按照Baruch的说明启用详细的scsi日志logging。 我在/ 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
到目前为止没有太多有用的东西，但是磁盘已经进入了一个“安静”阶段。 一旦开始阻塞，我会尝试捕获输出。
迟到了，我以为要检查旧的内核错误消息。 没有任何东西直接出错。 只是一堆超时警告。
更新3
试图在100％的压力时间窗口读取scsi日志。 无错误或超时条目:-(
我们增加了一个硬盘。 目前我使用dd if=/dev/sda of=/dev/sdc bs=32M克隆dd if=/dev/sda of=/dev/sdc bs=32M （稍后我会在离线状态下使用rsync进行另一次传递）。 我希望这一天能够结束。
我会在几天内再次更新结果。
更新4
由于我们托pipe公司的问题，我们无法完全切换到新磁盘。 在问题解决之前，我们只将数据库移动到新磁盘上。 这是当前的布局（只有相关的设备）：
/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
/dev/sdc是（可能）坏的磁盘。 /dev/sda是现在有数据库的新磁盘。
下一步就是监测情况，看看100％的使用情况是否会恢复。 我会在几天内更新（并希望在接受的答案后发布）。
你很可能有一个磁盘问题。 磁盘失败，一种相当常见的失败方法是由于磁盘上某些有问题的区域的重试次数增加而产生更高的延迟，当这些区域被命中时将引起等待它们的其他IO的连锁反应，并且如果有多个IO到受影响的地区，你会看到这样的问题，因为将有多个IO阻塞> 10秒。
我可以推荐使用diskscantesting磁盘，它会显示整个磁盘的延迟图。 它可以工作在只读模式，所以它不是破坏性的。 您也可以要求它修复可读性非常低的区域，但首先testing磁盘以查看它的行为。
问题可能是间歇性的，所以不会被diskcan发现。 您可以运行iosnoop来收集所有IO及其延迟的历史logging。 该脚本增加了一些开销，但非常好地工作。 如果问题不经常发生，它可能需要一些脚本才能进行更长的日志logging会话。
您可以增加scsi子系统日志logging级别以尝试从内核获取更多信息，如果使用LSI SAS HBA访问磁盘，则可以增加mpt2sas驱动程序的日志logging级别以获取更多信息。 两者都可以帮助查看是否有超时和在内核中止。 检查是否可以在内核中看到有关超时和已经中止的日志消息，它们可能是另一个线索。
编辑1：
要启用SCSIdebugging日志logging，您可以使用以下命令： echo 9411 > /proc/sys/dev/scsi/logging_level您可能需要为sys文件使用不同的位置。
也尝试运行smartctl与-x选项，它会显示最后几个错误，如果有的话。