因此,我们的主服务器上的其中一个HDD存在问题. / dev / sda有两个分区,一个安装为/,另一个用作Postgresql数据驱动器(/ dev / sda2).
$df -hfilesystem Size Used Avail Use% Mounted onrootfs 92G 13G 75G 14% /udev 10M 0 10M 0% /devtmpfs 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/locktmpfs 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) SELECT24359 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 --allsmartctl 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: 16vendor 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 - 2192 Power-Off_Retract_Count 0x0032 200 200 000 old_age Always - 2193 Load_Cycle_Count 0x0032 200 200 000 old_age Always - 9194 Temperature_Celsius 0x0022 112 109 000 old_age Always - 35196 Reallocated_Event_Count 0x0032 200 200 000 old_age Always - 0197 Current_Pending_Sector 0x0032 200 200 000 old_age Always - 0198 Offline_Uncorrectable 0x0030 100 253 000 old_age Offline - 0199 UDMA_CRC_Error_Count 0x0032 200 200 000 old_age Always - 0200 Multi_Zone_Error_Rate 0x0008 200 200 000 old_age Offline - 0SMART Error Log Version: 1No Errors LoggedSMART Self-test log structure revision number 1Num 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/sdadiskscan version headI: ValIDating path /dev/sdaI: Opened disk /dev/sda sector size 512 num bytes 1000204885504I: Scanning disk /dev/sda in 65536 byte stepsI: Scan started at: Sun Aug 31 04:21:33 2014Access 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: 0above that: 0 1290 | | | ^ | | 1075 | | | ^ | | 860 | ^ | ^ ^ | | ^ ^ ^ ^ ^ | ^ ^^ ^ ^ 645 | ^^ ^ ^ ^^^ ^ ^ ^ ^^^^^ ^^ ^ | ^ ^ ^ ^ ^ ^ ^^^ ^ | ^ ^ ^ ^ ^ ^ ^^ | ^ ^ ^ ^ | ^ ^ ^ ^ 430 | ^ ^^^ ^ ^ ^ | | ^ ^ ^^ | | 215 | | | | ********************************************************************** | ______________________________________________________________________ +-----------------------------------------------------------------------Conclusion: passedI: Scan ended at: Sun Aug 31 09:22:34 2014I: Scan took 18061 secondI: 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 00Aug 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 00Aug 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 00Aug 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 00Aug 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 00Aug 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
到目前为止没有什么过于有用,但磁盘已进入“安静”阶段.一旦它再次开始阻塞,我会尝试捕获输出.
姗姗来迟,我想检查较旧的内核错误消息.没有任何东西d出作为直接错误.只是一堆超时警告.
更新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％使用率突发是否返回.我会在几天内更新(并希望发布接受的答案).
解决方法 您很可能遇到磁盘问题.磁盘出现故障,一种相当常见的故障方法是由于磁盘上某些有问题区域的重试次数增加而导致更高的延迟,这些区域在被命中时将导致其他IO等待它们的连锁反应以及是否存在多个IO对于受影响的区域,您会看到这样的问题,因为将有多个IO阻止> 10秒.我建议用diskscan测试磁盘,它会显示磁盘上的延迟图.它可以在只读模式下工作,因此根本不具有破坏性.您还可以要求它修复可读但非常慢的区域,但首先测试磁盘以查看其行为方式.
问题可能是间歇性的,因此不会被diskcan注意到.您可以运行iosnoop来收集所有IO及其延迟的历史记录.该脚本增加了一些开销,但工作得非常好.如果问题不经常发生,则可能需要一些脚本来进行更长的日志记录会话.
您可以增加scsi子系统日志记录级别以尝试从内核中获取更多信息,如果使用LSI SAS HBA访问磁盘,则可以增加mpt2sas驱动程序的日志记录级别以获取更多信息.两者都可以帮助查看内核中是否存在超时和中止.检查您是否可以在内核中看到有关超时和中止的日志消息,它们可能是另一条线索.
编辑1：
要启用SCSI调试日志记录,您可以使用以下命令：echo 9411> / proc / sys / dev / scsi / logging_level您可能需要为sys文件使用不同的位置.
还尝试使用-x选项运行smartctl,如果有的话,它会显示一些最后的错误.
总结以上是内存溢出为你收集整理的linux – HDD正在起作用,但S.M.A.R.T说一切都很好全部内容，希望文章能够帮你解决linux – HDD正在起作用,但S.M.A.R.T说一切都很好所遇到的程序开发问题。
如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）