新しい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に接続されている負荷が少ない場合（74台のSATAドライブではなく60台）、この問題は発生しません。
- 74台のSATAドライブが接続されている間、14分で「ワット数が増加するかどうか」メーターが突然増加した消費電力を測定し始めました。つまり、326ワットではなく435ワットです。
- 14分の急激な電力増加は、ストレージモジュールがカーネルにロードされていない（/ dev / sdbなどなし）、他のbpo.3およびbpo.4カーネルバージョンでも発生します。
アップデート＃3: 1 つのブートドライブを除くすべてのドライブは分割されず、フォーマットされず、マウント解除されます。
アップデート＃4cat /proc/diskstats | grep " sd": Hitachi/Toshiba HDS5C ドライブがより多くの電力を消費し始める問題そうです。起動後に作成されたセクタの数を合計するとゼロになり、消費電力が急増し始めると、この数字は変わりません。
問題は、これらの再起動が次の原因で発生するかどうかを確認する方法です。
- ソフトウェア
- ハードウェア（例：短絡状態に対する電源の過電流保護）？
ベストアンサー1
「ワット数の増加？」を使用して、システムの消費電力をより詳細に監視します。電力計は、これらの再起動が電源装置の過電流保護（OCP）の活性化によって引き起こされることを保証します。
起動後15分後に電力消費が増加した理由を尋ねる質問にserverfaultの答えは、起動後15分後に74ドライブすべてが自動オフラインSMART（ハードドライブセルフモニタリング、分析、レポート）を同時に実行し始めることができるということです。 。時間技術）テスト。
次の試みは、自動オフラインテストの実行を無効にすることでしたsmartctl --offlineauto=off /dev/sdx。 20時間が経過したため、電源投入や再起動なしで、最初の結論は、定期的なオフラインSMARTテストを実行するようにドライブを設定したことが原因でした。