新建的 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/messages
或tail -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 点之间重新启动。