如何调试重启是软件原因还是硬件原因?

如何调试重启是软件原因还是硬件原因?

新建的 Linux debian 2.6.32-5-amd64 #1 SMP Sun Sep 23 10:07:46 UTC 2012 x86_64 GNU/Linux 服务器经历了多次重启。

' last -x' 输出显示:

root     pts/0        192.168.254.11   Sat Dec 15 13:13   still logged in   
runlevel (to lvl 2)   2.6.32-5-amd64   Sat Dec 15 13:10 - 13:17  (00:06)    
reboot   system boot  2.6.32-5-amd64   Sat Dec 15 13:10 - 13:17  (00:06)    
runlevel (to lvl 2)   2.6.32-5-amd64   Sat Dec 15 12:53 - 13:10  (00:17)    
reboot   system boot  2.6.32-5-amd64   Sat Dec 15 12:53 - 13:17  (00:23)    
runlevel (to lvl 2)   2.6.32-5-amd64   Sat Dec 15 12:36 - 12:53  (00:17)    
reboot   system boot  2.6.32-5-amd64   Sat Dec 15 12:36 - 13:17  (00:40)    
runlevel (to lvl 2)   2.6.32-5-amd64   Sat Dec 15 12:19 - 12:36  (00:17)    
reboot   system boot  2.6.32-5-amd64   Sat Dec 15 12:19 - 13:17  (00:57)    
root     pts/0        192.168.254.11   Sat Dec 15 12:04 - crash  (00:14)    
runlevel (to lvl 2)   2.6.32-5-amd64   Sat Dec 15 12:01 - 12:19  (00:17)    
reboot   system boot  2.6.32-5-amd64   Sat Dec 15 12:01 - 13:17  (01:15)    
runlevel (to lvl 2)   2.6.32-5-amd64   Sat Dec 15 11:44 - 12:01  (00:17)    
reboot   system boot  2.6.32-5-amd64   Sat Dec 15 11:44 - 13:17  (01:32)    
root     pts/0        192.168.254.11   Sat Dec 15 11:36 - crash  (00:08)    
runlevel (to lvl 2)   2.6.32-5-amd64   Sat Dec 15 11:26 - 11:44  (00:18)    
reboot   system boot  2.6.32-5-amd64   Sat Dec 15 11:26 - 13:17  (01:50)    
runlevel (to lvl 2)   2.6.32-5-amd64   Sat Dec 15 11:08 - 11:26  (00:17)    
reboot   system boot  2.6.32-5-amd64   Sat Dec 15 11:08 - 13:17  (02:08)    
runlevel (to lvl 2)   2.6.32-5-amd64   Sat Dec 15 10:51 - 11:08  (00:17)    
reboot   system boot  2.6.32-5-amd64   Sat Dec 15 10:51 - 13:17  (02:25)    
runlevel (to lvl 2)   2.6.32-5-amd64   Sat Dec 15 10:34 - 10:51  (00:17)    
reboot   system boot  2.6.32-5-amd64   Sat Dec 15 10:34 - 13:17  (02:42)    
root     pts/0        192.168.254.11   Sat Dec 15 02:41 - crash  (07:53)    
runlevel (to lvl 2)   2.6.32-5-amd64   Sat Dec 15 02:32 - 10:34  (08:02)    
reboot   system boot  2.6.32-5-amd64   Sat Dec 15 02:32 - 13:17  (10:45)    
runlevel (to lvl 0)   2.6.32-5-amd64   Sat Dec 15 02:12 - 02:32  (00:19)

top在发生崩溃/重新启动之前不到 0.1 秒,“ ”命令的输出:

top - 15:14:04 up 16 min,  2 users,  load average: 0.00, 0.00, 0.01
Tasks: 163 total,   1 running, 162 sleeping,   0 stopped,   0 zombie
Cpu0  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu1  :  0.0%us,  8.3%sy,  0.0%ni, 91.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu2  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu3  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   8191048k total,    87356k used,  8103692k free,     2432k buffers
Swap:        0k total,        0k used,        0k free,    20120k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                       
 2296 root      20   0 19072 1432 1032 R    9  0.0   0:10.25 top                                                                                                            
    1 root      20   0  8356  820  684 S    0  0.0   0:00.79 init                                                                                                           
    2 root      20   0     0    0    0 S    0  0.0   0:00.00 kthreadd                                                                                                       
    3 root      RT   0     0    0    0 S    0  0.0   0:00.00 migration/0                                                                                                    
    4 root      20   0     0    0    0 S    0  0.0   0:00.03 ksoftirqd/0                                                                                                    
    5 root      RT   0     0    0    0 S    0  0.0   0:00.00 watchdog/0                                                                                                     
    6 root      RT   0     0    0    0 S    0  0.0   0:00.00 migration/1                                                                                                    
    7 root      20   0     0    0    0 S    0  0.0   0:00.00 ksoftirqd/1                                                                                                    
    8 root      RT   0     0    0    0 S    0  0.0   0:00.00 watchdog/1                                                                                                     
    9 root      RT   0     0    0    0 S    0  0.0   0:00.00 migration/2                                                                       

第 16 分钟的“ Sensors”输出显示:

temp1:       +37.0 C  (high = +60.0 C, hyst = +55.0 C)  sensor = thermistor
temp2:       +75.0 C  (high = +95.0 C, hyst = +92.0 C)  sensor = diode
temp3:       +32.0 C  (high = +75.0 C, hyst = +70.0 C)  sensor = thermistor

更新#2:

  • 运行时,top该问题通常发生在正常运行时间的第 16 分钟。
  • 当 Corsair 1050HX PSU 连接的负载较少(60 个而不是 74 个 SATA 驱动器)时,该问题永远不会发生。
  • 连接了 74 个 SATA 驱动器后,第 14 分钟“瓦特增加了吗?”仪表突然开始测量增加的功耗值:435 瓦而不是 326 瓦。
  • 第 14 分钟功率突然增加也发生在其他 bpo.3 和 bpo.4 内核版本中,其中存储模块未加载到内核中(没有 /dev/sdb 等)

更新#3:除一个启动驱动器外,所有驱动器均未分区、未格式化且未安装。

更新#4:日立/东芝 HDS5C 驱动器开始消耗更多电量的问题 - 5.34W 而不是 3.5W,没有任何读/写活动 - 15 分钟后更多功率似乎与操作系统(软件)无关,因为cat /proc/diskstats | grep " sd"返回 224 个扇区读取和 0启动后写入的扇区数,当功耗开始激增时,该数字保持不变。

问题是如何查明这些重启是否是由以下原因引起的:

  • 软件
  • 硬件(例如电源过流保护的短路情况)?

答案1

使用“瓦特增加?”更密切地监控系统的功耗。瓦特表使人们更加确信这些重启是由电源上启动的过流保护 (OCP) 引起的。

当询问为什么启动 15 分钟后会出现功耗增加的情况时,serverfault 给出的答案是,启动 15 分钟后,所有 74 个驱动器可能同时开始运行其自动离线 SMART(硬盘驱动器的自我监控、分析和报告技术)测试。

接下来的尝试是禁用运行自动离线测试smartctl --offlineauto=off /dev/sdx:由于现在已经 20 小时不再出现功耗峰值或重新启动,初步结论是驱动器运行定期离线 SMART 测试的设置是原因。

答案2

首先,72 个硬盘驱动器很多(我最大的机器只有 24 个……并且有 1200W 电源)我希望您使用的是交错旋转。

您可能会看到驱动器开始离线数据收集。这可以解释用电量的增加。这也意味着,如果您要实际使用驱动器,您可能会将功耗至少提高到同样高。

您的驱动器规格表显示 12V 电源轨上的峰值电流为 2A。你的电源声称它可以在 12V 电源轨上提供 87.5A 的电流。因此,您可以很容易地超过这个值,特别是因为其他组件也需要其中一些。您可能需要在该轨道上安装一个电压表(如果可能的话,还有电流表),看看是否发生了这种情况。

我将继续猜测答案是“是”。与驱动器数量相比,您运行的供应量很小。例如,我们使用的系统构建器制造了具有 1400W 电源的 45 驱动器 JBOD,而且您还有更多驱动器和一台计算机。当然,该 JBOD 可能指定用于 15K SAS 驱动器。但您还有额外的 27 个驱动器。

调试软件崩溃(这可能不是)

您想要尝试查找软件崩溃的主要事情是获取内核日志直到最后一秒。如果您有串行端口,最好的选择是连接另一台计算机并使用串行控制台(将 console=/dev/ttyS0,57600 添加到内核命令行)。第二好的方法是使用 netconsole,在机器启动后(但在 16 分钟结束之前)您可以轻松配置它:

首先,在其他机器上运行nc -l -u -p 1234.然后,在总是崩溃的机器上,modprobe netconsole netconsole=@/eth0,1234@some-ip/.您应该立即在 netcat 窗口中看到一些控制台消息:

[508073.196581] console [netcon0] enabled
[508073.197026] netconsole: network logging started

当然,你的时间戳会低得多。

答案3

根据您的输出last -x,似乎每 17-18 分钟重新启动一次,因此您首先需要检查是否有任何脚本或 cron 设置为重新启动?如果没有,请阅读下文。

您可以签入与硬件相关的错误dmesg | tail,或者可以在您通常在服务器中运行的特定应用程序tail -f /var/log/messagestail -f /var/log/syslog(基于 debian)的日志中找到与软件相关的日志。

如果您想快速检查是软件问题还是硬件问题,那么您应该检查top

hi  --  Hardware IRQ
          The amount of time the CPU has been servicing hardware interrupts.

si  --  Software Interrupts
          The amount of time the CPU has been servicing software interrupts.

在此输入图像描述

此外,您还必须检查顶部的 %wa 值,以防万一您的硬盘出现问题,那么该值将会增加。所以你可以检查使用hdparam -T /dev/sdx和其他工具。但这还不是最终的,可能还有很多方法可以检查。

答案4

您必须检查 CPU 温度,您可以使用以下命令检查系统日志:- grep 'temperature' /var/log/syslog 如果上述命令输出为空,则您必须安装该lm-sensors软件包并运行,sudo sensors-detect对所有是/否问题选择“是”。在传感器检测结束时,将显示需要加载的模块列表。输入“yes”让传感器检测将这些模块插入到 /etc/modules 中,或者自己编辑 /etc/modules 。接下来,运行sudo service module-init-tools restart这将读取您在步骤 3 中对 /etc/modules 所做的更改,并将新模块插入到内核中。接下来,您应该测试 lm 传感器是否正常工作。运行sensors命令并检查是否有可能的后期输出。我认为您需要在系统启动时间 15 分钟后运行此命令,因为每次在 17 点到 18 点之间重新启动。

相关内容