Home Assistantにはどの程度のメモリ上限を設定すべきですか？

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

What Memory Limit Should You Set for Home Assistant? - Zima Store Online

Home Assistant のメモリ上限に、唯一の正解はありません。実測したピーク値を基準に上限を設定し、ホストと他のコンテナのために使用可能な RAM を残してください。また、OOM キルが発生した場合は、上限またはワークロードを調査する必要がある証拠と考えましょう。

共有ホームサーバーでは、アイドル時の値だけでは不十分です。Recorder の処理、バックアップ、インテグレーションの再読み込み、ダッシュボード、家全体で自動化が集中する処理によって、ピーク値は異なります。安全な方法は、ベースラインを記録し、確認済みのワークロードのピークを上回る、変更を元に戻せる上限を設定することです。そのうえで、ホストに十分な余裕があることを確認し、設定を恒久化する前に、元の負荷が高い時間帯を再テストします。

一般的な RAM 容量ではなく、ピーク使用量から始める

通常の数日間、Home Assistant コンテナとホストを同時に測定します。再起動、バックアップ、使用している場合はデータベースのパージまたは再パック、ダッシュボードの操作、そして安全に再現できる最も負荷の高い自動化の時間帯を含めてください。コンテナのピーク値、ホストの使用可能メモリ、スワップの使用状況、応答時間の変化を記録します。

メモリ上限は cgroup の境界であり、性能目標ではありません。コンテナがハード上限を超えると、カーネルがプロセスを終了させることがあります。終了コード 137 と OOM キル状態が同時に確認できる場合は、典型的な兆候です。そのため、平均値やどこかからコピーした推奨値よりも、実測したピーク使用量が重要になります。

処理中にメモリが増加し、処理後に落ち着くのであれば、再現可能なピーク値に作業用の余裕を加えて容量を決めます。ワークロード終了後も匿名メモリが何時間も増え続け、元に戻らない場合は、容量設定を続けるのではなく、メモリリークを起こしているインテグレーション、カスタムコンポーネント、またはバージョンのリグレッションを調査してください。上限を引き上げるだけでは、クラッシュを遅らせるだけで問題は解決しない可能性があります。

ホストと同居するすべてのサービスのためにメモリを確保する

Home Assistant が最も忙しいときにも応答性を維持する必要があるサービスを一覧にします。オペレーティングシステム、Docker、データベース、MQTT、DNS、ダッシュボード、メディアサービス、バックアップジョブなどです。上限は Home Assistant だけでなく、これらのサービスも保護できるように設定する必要があります。搭載 RAM のほぼすべてを1つのコンテナに割り当てると、障害がホスト側へ移るだけです。

同じ時間帯における Home Assistant のピーク値と、ホストの使用可能メモリを比較します。再利用可能なキャッシュはアプリケーションメモリと同じではありません。また、スワップが発生すると、システムが動作しているように見えてもデバイス制御が遅くなることがあります。Home Assistant がピークに達する前にホストの余裕がなくなる場合は、Home Assistant の上限を厳しくする前に、重複するジョブを減らすか、サービスを移動してください。

これは単なる Docker の設定ではなく、容量に関する判断です。関連する ZimaSpace のウォームキャッシュを超えて Home Assistant を測定する方法ガイドでは、都合のよいアイドル時のスナップショットよりも、再現可能なコールド状態と高負荷のワークロードによって、信頼性の高いベースラインを得られる理由を説明しています。

元に戻せる上限を適用し、適用されていることを確認する

Compose ファイルやオーケストレーション UI など、実際にコンテナを再作成する設定にメモリ設定を追加します。次回のデプロイで破棄される可能性がある、一時的なライブ更新だけに頼らないでください。すぐに復元できるよう、変更前の設定を保存しておきます。

再作成後、実行中のコンテナを確認し、設定した上限が表示されていることを確認します。その後、コンテナの使用量、ホストの使用可能メモリ、スワップ、再起動回数、レイテンシを監視します。ホストの cgroup によって表示された設定が実際には適用されていない場合、特にネストされた仮想化環境では、誤った安心感につながります。

コンテナが再起動しても、すぐに上限を引き上げないでください。ランタイムが OOMKilled と終了コード 137 を報告しているか確認します。そうでなければ、別のシャットダウン経路を調査してください。該当する場合は、タイムスタンプをワークロードと照合します。短時間のピークが繰り返し発生しているなら作業用の余裕が不足している可能性があり、継続的な増加ならメモリリークまたは制御不能になったインテグレーションが疑われます。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

元の負荷が高い Home Assistant のワークロードで再テストする

ベースラインに使用したシナリオをそのまま再現します。同じインテグレーションを再読み込みし、同じダッシュボードを開き、同じ家全体の制御シーケンスを実行し、同じバックアップまたは Recorder の処理も含めてください。ワークロードを変更すると、より軽いシステムで動作したことしか証明できません。

テストに合格したといえるのは、コンテナが OOM イベントなしに上限未満で動作し、ホストに使用可能なメモリが残り、スワップによる制御遅延が発生せず、自動化が通常の速度で完了する場合です。再起動を2回行って再度確認し、次回の定期バックグラウンドジョブの後にも確認してください。これにより、再作成や時間ベースの処理後も結果が維持されることを確認できます。

デバイス制御が不安定になった場合、コンテナが再起動ループに入った場合、またはホストのメモリ圧迫が深刻なままの場合は、新しい上限を元に戻します。原因となったワークロードの終了後もメモリが増え続ける場合は、インテグレーションの切り分けやバージョン比較に進んでください。その段階では、上限の調整はもはや主な修復方法ではありません。

FAQ

Home Assistant には常にハードメモリ上限を設定すべきですか？ 共有 Docker ホストでは、検証済みの上限によって他のサービスを保護できます。専用の HAOS マシンや VM では容量の考え方が異なるため、コンテナの上限を測定なしに VM の割り当てへそのまま適用しないでください。

使用メモリが多い場合、それは自動的にメモリリークですか？ いいえ。キャッシュや短時間のワークロードによるピークは正常な場合があります。匿名メモリが増え続けているか、OOM イベント、再起動ループ、ワークロード終了後のレイテンシ悪化がないかを確認してください。

スワップを無効にすべきですか？ 最初に行うべきではありません。まず、スワップがホストのメモリ圧迫を隠しているのか、突然の障害を防いでいるのかを把握します。そのうえで、テスト済みのロールバック手順と、ワークロード全体に十分な物理 RAM がある場合にのみ変更してください。