因此,我们的主服务器上的其中一个HDD存在问题. / 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
(/ 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] ...
我们知道这是由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
你可能会想：“只是优化你的DB,伙计.神秘的地方在哪里？”
但是,请考虑以下三点：
>还有另一个相同应用程序的实例,在类似的负载下在/ 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 - ...
如您所见,smartctl表示一切正常.我甚至做了一个完整的测试,没有发现任何错误.
所以我在这里不知所措.一切都指向一个失败的硬盘驱动器,但S.M.A.R.T监控没有检测到任何东西.
我的问题：
>我的诊断是否正确？驱动器真的失败了吗？
>如果是,我如何得到一些报告,我可以向托管公司展示,以便他们同意更换它？
>如果不是,那么下一个最可能的罪魁祸首是什么？
更新1
根据巴鲁克的建议,我执行了光盘扫描.不幸的是,它找不到任何我能指出的东西.
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脚本(由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
到目前为止没有什么过于有用,但磁盘已进入“安静”阶段.一旦它再次开始阻塞,我会尝试捕获输出.
姗姗来迟,我想检查较旧的内核错误消息.没有任何东西弹出作为直接错误.只是一堆超时警告.
更新3
尝试在100％压力时间窗口内读取scsi日志.没有错误或超时条目:-(
我们添加了另一个硬盘目前我用dd if = / dev / sda = = 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
/ dev / sdc是(可能)坏磁盘. / dev / sda是现在拥有数据库的新磁盘.
下一步是监控情况并查看100％使用率突发是否返回.我会在几天内更新(并希望发布接受的答案).
解决方法
我建议用diskscan测试磁盘,它会显示磁盘上的延迟图.它可以在只读模式下工作,因此根本不具有破坏性.您还可以要求它修复可读但非常慢的区域,但首先测试磁盘以查看其行为方式.
问题可能是间歇性的,因此不会被diskcan注意到.您可以运行iosnoop来收集所有IO及其延迟的历史记录.该脚本增加了一些开销,但工作得非常好.如果问题不经常发生,则可能需要一些脚本来进行更长的日志记录会话.
您可以增加scsi子系统日志记录级别以尝试从内核中获取更多信息,如果使用LSI SAS HBA访问磁盘,则可以增加mpt2sas驱动程序的日志记录级别以获取更多信息.两者都可以帮助查看内核中是否存在超时和中止.检查您是否可以在内核中看到有关超时和中止的日志消息,它们可能是另一条线索.
编辑1：
要启用SCSI调试日志记录,您可以使用以下命令：echo 9411> / proc / sys / dev / scsi / logging_level您可能需要为sys文件使用不同的位置.
