Home Assistantのピーク時にどれくらいCPUの余裕を確保すべきですか？
最も負荷が高く、再現可能なワークロードに対して十分なCPU余力を確保し、イベント発生からアクション実行までの時間と再起動後の復帰目標を満たします。すべてのHome Assistant構成に当てはまる、正当化可能な普遍的割合はありません。
4コアのホストでは、平均使用率が控えめでも1コアだけが飽和することがあります。また、CPUがボトルネックに見えても、実際の限界はストレージ待ち、メモリ圧迫、サーマルスロットリングかもしれません。現実的に最も忙しい重複状態を定義し、制御レイテンシーとコアごとの挙動を測定したうえで、通常の関連サービスを停止せず、繰り返し合格できる最小限のリソース余力を維持します。
ピークとユーザーに影響する上限を定義する
通常時に最も忙しい自動化の集中処理に、ダッシュボードの利用と、バックアップ、データベースのメンテナンス、音声処理、選択したカメラ処理など、予定されたバックグラウンドジョブを組み合わせたワークロードを1つ作成します。使用率を測定する前に、許容可能なイベントからアクションまでのレイテンシー、ダッシュボードの応答性、再起動後に利用可能になるまでの時間を定義します。
人工的な全コア負荷テストだけをピークとして使用しないでください。これはハードウェアの処理能力は測定できますが、ユーザーが実際に体験するスケジューリング、データベース、インテグレーション、アドオンの重複負荷は測定できません。
有効なベースラインでは、同じデバイス数、インテグレーション、データベース状態、周辺サービスを使って3回実行します。ワークロードを再現できない場合、そこから算出した割合は信頼できる予備容量とはいえません。
比較対象として、負荷の低い時間帯の実行結果も記録します。低負荷時とピーク時の差からワークロードへの感度が分かります。ピーク時の割合だけでは、システムが飽和寸前の状態から始まっていたかどうかは判断できません。
コアごとの飽和と待機を分けて確認する
ユーザーに影響するレイテンシーと同時に、コアごとの使用率、ロード、仮想マシンのスティール時間、I/O待ち時間、周波数、温度、Home Assistantプロセスを記録します。すべての測定値を同じタイムスタンプにそろえます。
1つのコアが飽和していても、システム全体の平均使用率がはるかに低く見えることがあります。そのため、全体の使用率が利用可能な余力を示すと決めつけず、プロセスの負荷分布を確認します。
レイテンシーの上昇と同時に1つのコアが張り付く場合は、CPUのシングルスレッド性能不足またはブロッキング処理が疑われます。I/O待ち時間が先に上昇する場合は、ストレージまたはデータベースの動作を改善します。温度上昇に伴って周波数が低下する場合は、名目上の容量をさらに確保する前に冷却を改善します。
スケジューリングと分離で余力を作る
オプションのジョブを最も忙しい制御時間帯から移動し、負荷の大きい関連コンテナを制限します。また、カメラ、AI、メディア処理が実行可能なコアをすべて消費しないようにします。ピーク時にもHome Assistantと重要なブローカーが処理を継続できる状態を保ちます。
現在のシステムの制限要因を測定した後にのみ、ワークロードに基づくプロセッサの余力を比較します。より高速な製品に買い替えても、制限のないジョブやストレージ待ちは解決しません。
スケジューリングや制限を変更するたびに再テストします。ハードウェアを変更せずにレイテンシーの条件を満たせた場合、回復した余裕は運用上のヘッドルームです。同じコアが飽和し続ける場合は、同一のワークロードに対してのみ、より高性能なCPUを比較します。
繰り返し合格した結果から予備容量を設定する
再現性のあるクリーンな実行を繰り返し、その中で観測された最大ピークを基準にします。次に、想定されるインテグレーションの増加と、メンテナンス処理が1つ重なる可能性に備えて、追加の容量を確保します。結果は普遍的なアイドル時目標ではなく、テスト済みのサービス運用範囲として表します。
リソース余力のベンチマークに記載された手順では、CPU、メモリ、ストレージ、ネットワークを横断したベースラインを確認できます。
元のピーク負荷で、サーマルスロットリングやサービスの強制停止なしに、連続した実行でレイテンシーと再起動の目標を満たせれば合格です。スケジューリング、インテグレーション、I/Oに起因する要因を除外した後も同じCPU固有の飽和が残る場合は、対策を強化するかアップグレードします。
おすすめ商品
サポートとヒント
もっと読む
同時稼働するコンテナ向けに Immich のデータベース接続を最適化する方法
まず max_connections を増やさないでください。Immich のセッション数を測定し、すべてのコンテナの需要を合計し、管理用の余裕を確保したうえで、実証されたボトルネックだけを調整してください。
Immichでジョブやインポートの重複を防ぐ方法
重複するジョブと重複アセットを分離します。正規の取り込み経路を1つに統一し、再試行とパス変更を制御してから、小規模なコホートで再エントリーをテストします。
データベースのボリュームがいっぱいになった後に Immich を修復する方法
空き容量を確保するためにPostgreSQLのWALを削除しないでください。Immichへの書き込みを停止し、データベースの状態を保持したまま安全に容量を追加し、PostgreSQLを復旧してから、再発を防止してください。
