夏に自宅サーバーが落ちる前に:CPU温度の記録方法と設置・冷却の見直し

Photo: panumas nikhomkhai / Pexels
自宅サーバーで一番やっかいな止まり方は、落ちた理由が何も残らない止まり方です。朝になったら NAS が見えない、Proxmox の Web UI が開かない。再起動すれば普通に動く。ログを見ても、落ちる直前でぷつんと切れているだけで原因らしき行がない。
この「証拠が残らない落ち方」は、熱が絡んでいることがよくあります。温度が上限に達したときの保護は、OS の停止処理を待たずにハードウェア側で電源を切ってしまうため、ログに書き込む時間そのものが無いからです。
つまり、落ちてから調べても分かりません。先にやるべきは温度を記録しておくことです。この記事では、確認 → 記録 → 判断 → 対処の順に整理します。残暑が終わるこの時期に仕込んでおくと、来年の夏にそのまま効きます。
ステップ1:まず今の温度を見る
一番手軽なのは lm-sensors です。
sudo apt install lm-sensors
sensors
Package id 0 や Tctl といった行に現在値が出ます。パッケージを増やしたくない場合は、カーネルが公開している値を直接読めます。
cat /sys/class/thermal/thermal_zone0/temp
返ってくるのはミリ度(54000 なら 54℃)です。Raspberry Pi なら専用のコマンドもあります。
vcgencmd measure_temp
ここで見た値は「今の値」でしかありません。問題が起きるのは日中の暑い時間帯や、バックアップ・トランスコードが重なった瞬間です。人が見ていないときの値を残す必要があります。
ステップ2:記録する(まずは cron と CSV で十分)
Prometheus と Grafana をすでに動かしているなら、node_exporter の node_hwmon_temp_celsius をそのまま使えます。可視化まで含めて一番きれいな形です。
ただ、監視基盤を持っていない段階で「温度のために監視基盤を作る」のは順番が逆になりがちです。まずは 1 分ごとに CSV へ追記するだけで判断材料になります。
# crontab -e
* * * * * echo "$(date +\%F' '\%T),$(cat /sys/class/thermal/thermal_zone0/temp)" >> /var/log/cputemp.csv
記録先は落ちても消えない場所にしてください。/tmp に置くと再起動で消えます。あとで表計算ソフトに貼れば、何時ごろに何度まで上がっていたかがすぐ見えます。
落ちた前後を確認するときは、この CSV と合わせて次の 2 つを見ます。
journalctl -b -1 -e # 前回起動分の最後のログ
last -x | head # 再起動・シャットダウンの記録
last -x に shutdown の行が無いまま reboot だけが並んでいたら、OS が停止処理をしていない落ち方です。熱、電源、ハードウェア障害のどれかに絞れます。
ステップ3:何度からまずいのかを知る
数字の意味が分からないと、記録を取っても判断できません。
| 対象 | 目安 |
|---|---|
| Intel の CPU | 上限(Tjmax)は 100℃前後に設定されているとされています |
| Raspberry Pi 5 / 4 | 80℃ でソフト上限、85℃ でさらに強く制限されるとされています |
| NVMe SSD | 70〜80℃前後が警告しきい値として設定されていることが多いです |
| HDD | 仕様上の動作範囲はおおむね 0〜60℃ 程度 |
重要なのは、上限に触れる前から性能が落ちていることです。CPU は上限に達する前に周波数を下げて発熱を抑えます。これがサーマルスロットリングで、「落ちてはいないが妙に遅い」の正体であることがあります。
Raspberry Pi は、起きたかどうかを直接確認できます。
vcgencmd get_throttled
throttled=0x0 なら問題なしです。値が付いている場合、下位のビットが「今の状態」、上位のビット(0x50000 のような形)が「起動してから一度でも発生したか」を表します。電圧低下のビットが立っていたら、それは熱ではなく電源の問題です。純正相当の電源とケーブルに替えるのが先になります。
ステップ4:CPU 以外も疑う
温度で落ちる構成を見ていくと、CPU 以外が効いていることが珍しくありません。
- NVMe SSD:ミニPC の中は風が通りません。
sudo smartctl -a /dev/nvme0n1でTemperatureとWarning Composite Temperature Timeを確認します。後者が増えていたら、しきい値を超えた時間が積み上がっているということです - HDD:NAS で複数台を密に並べると上がります。
smartctl -A /dev/sdaで確認します - 電源アダプタ:本体より先に熱くなっていないか、手で触って確かめます
- ONU・ルーター:サーバーは無事でも、ここが落ちれば「外から繋がらない」は同じように起きます
「サーバーが落ちた」と思っていたら、実はネットワーク機器のほうが先に音を上げていた、というのはよくある勘違いです。
ステップ5:設置を直す(費用ゼロで効く順)
冷却部品を買う前に、置き方で直る分を先に回収します。
- 吸気と排気の面を塞がない。ミニPC は底面吸気の機種が多く、カーペットや本の上に直置きすると吸えなくなります
- 積み重ねない。上の機器の排気を下の機器が吸う形になります
- 壁との距離を取る。背面排気なら数センチでも変わります
- 埃を取る。吸気口のフィルターとファンの埃は、そのまま温度に乗ります
- クローゼットや棚の中に閉じ込めない。静かにしたくて扉の中に入れた結果、熱がこもるパターンです
- 直射日光と床の高さ。窓際と床付近は条件が悪くなりがちです
私の環境でも、机の下の奥に押し込んでいたミニPCを手前に出して背面を空けただけで、体感の風量が変わりました。まず無料でできる範囲を試す価値はあります。
ステップ6:それでも足りないとき
ここから先はお金と静音性とのトレードオフになります。
- 底面・側面に小型ファンを当てる。USB 駆動の静音ファンをケース外から当てるだけでも効きます。サーバー本体を分解しないので戻すのも簡単です
- NVMe にヒートシンクを付ける。M.2 用ヒートシンクは数百円台からあります。ミニPC は内部クリアランスが狭いので、薄型を選ばないと蓋が閉まりません
- Raspberry Pi はアクティブクーラー。ケース内にファンを入れる構成が、5 以降では事実上の標準になっています
- 消費電力の上限を下げる。BIOS で PL1 / PL2(電力制限)を下げる、あるいは CPU ガバナを
powersaveにする方法です。性能は落ちますが、自宅サーバーの常用負荷なら気付かないことも多いです - 室温そのものを下げる。サーキュレーターで空気を動かす、機器のある部屋のエアコンを弱めに回し続ける、など
室温を記録するなら、スマート温湿度計を機器の近くに置いておくと、CPU 温度の CSV と突き合わせられます。「室温が上がった日だけ落ちている」と分かれば、対策の方向は決まったも同然です。
ステップ7:落ちる前に気づく仕組みにする
記録が取れたら、最後は通知です。しきい値を超えたらスマホに飛ばす形にしておくと、落ちる前に手を打てます。Uptime Kuma を使っているなら、温度を返す簡単なスクリプトを用意して監視対象に足すのが手っ取り早いです。
やりすぎないコツは、しきい値を上限ギリギリにしないことです。Raspberry Pi なら 70℃、Intel のミニPC なら 85℃ あたりで最初の通知を出し、そこから調整するくらいが現実的です。通知が鳴りすぎると、そのうち誰も見なくなります。
まとめ
- 熱で落ちるときはログが残らないため、事前に温度を記録しておくしかありません
- 記録は
cronで CSV に追記するだけで十分。再起動で消えない場所に書きます - 判断の目安は Raspberry Pi が 80℃、Intel が 100℃前後。上限前からスロットリングで遅くなります
vcgencmd get_throttledで電圧低下のビットが立っていたら、熱ではなく電源を疑います- CPU だけでなく NVMe・HDD・電源・ルーターも候補に入れます
- 対処は置き方の見直しが先、部品の追加は後。吸排気・積み重ね・埃で戻る分が大きいです
夏のあいだに一度でも落ちた覚えがあるなら、涼しくなった今のうちに記録だけ始めておくのがおすすめです。来年の暑い日に、比べる相手のあるデータが手元にある状態になります。
運営者が作った Excel テンプレートを BOOTH で配布しています。IT 資産管理台帳(無料 Lite 版あり) / IT 資格の学習管理シート


