Home AssistantがCPU、RAM、ストレージ、ネットワークのどれによって制限されているかを見分ける方法

Home Assistantのボトルネックを特定できるのは、まず再現性のある症状を1つ確認してからです。CPU使用率のグラフが高い、空きRAMが少ない、ディスクが忙しい、ネットワークカウンターの値が速いといったことだけでは不十分です。制約になっているリソースとは、自動化、ダッシュボード、履歴クエリ、インテグレーションが遅くなるのと同時に、その負荷が変化するリソースです。

まずテスト条件をそろえます。毎回、同じ自動化、デバイス、ダッシュボード、履歴の範囲、バックグラウンド負荷を使用してください。そのうえで、CPU、メモリ、ストレージ、ネットワークを個別に観察し、疑わしい制約を一度に1つだけ変更します。

リソースグラフを見る前に症状を定義する

「Home Assistantが遅い」とは、物理デバイスの動作が遅れる、ダッシュボードの描画に数秒かかる、履歴の読み込みが遅い、インテグレーションの再接続が遅い、バックアップ中にホストが停止する、といったさまざまな意味を持ちます。それぞれ異なるデータ経路を使用します。

再現可能なイベントを1つ選び、時刻を記録します。モーションライトなら、トリガーの到着時刻と物理的な反応時刻を記録します。履歴なら、クエリ開始から最初の結果が表示されるまでを測定します。ダッシュボードなら、サーバーの応答とブラウザの描画を分けて確認します。利用できないインテグレーションなら、ネットワーク到達性とインテグレーションのログを記録します。

無関係なグラフを十数個集めて、最も高いスパイクを探してはいけません。ユーザーに見える遅延が発生したとき、システムのどの段階が待機していたのかをテストで明らかにする必要があります。

処理待ちが計算処理の後ろに並ぶならCPUが制限要因

症状が悪化している間、Home Assistantまたは関連プロセスが継続的に計算リソースを消費し、その計算需要を取り除くか分離すると同じ負荷で改善する場合、CPUが有力な候補になります。

使用率、飽和度、エラーの手法は、単に忙しいだけのリソースと、処理が待ち行列に並んでいるリソースを区別できるため便利です。Home Assistantでは、短時間のCPUスパイクよりも、遅延した自動化やデータベース処理と一致する、再現性のある飽和状態のほうが重要です。

負荷の原因となっているプロセスまたはコンテナを確認します。カメラ処理、データベースのメンテナンス、ローカルAIコンテナ、コンパニオンサービスなどがホストを飽和させていても、Home Assistant自体の負荷は軽いままの場合があります。

ワーキングセットが負荷を生むならRAMが制限要因

Linuxは、ほかの用途で使われていないメモリをキャッシュに利用するため、「free」メモリが少ないことだけで問題とは限りません。利用可能メモリ、スワップ、メモリプレッシャー、cgroupの制限、OOMイベントを確認してください。

Linuxのファイルシステムキャッシュは解放可能という説明は、Home Assistantホストを読み解く際に重要です。RAMの大部分が使用中と表示されても、十分な余裕が残っているマシンはあります。

同じ通常負荷によって利用可能メモリが繰り返し減少し、スワップや回収処理の停止が発生したり、コンテナの制限に達したり、OOMキルが発生したりする場合、メモリが有力な制限要因になります。そのパターンが確認できてから、RAMを増設するか、アクティブなワーキングセットを減らしてください。

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

Recorderまたはバックアップの処理に合わせて遅延が変化するならストレージが制限要因

ストレージの負荷は、CPU使用率が低い状態に隠れていることがあります。Recorderへの書き込み、データベースクエリ、再パック、バックアップ、アップデート、その他のコンテナが同じデバイス上で処理待ちになっていても、CPUコアはほとんどアイドル状態のままの場合があります。

Home AssistantのRecorderバックログ警告は、CPUバウンド、I/Oバウンド、またはデータベースやストレージの問題があるシステムと明確に関連付けられています。そのため、このエラーを見たら、データベースを盲目的に置き換えるのではなく、相関関係を確認する必要があります。

ディスク遅延、I/O待ち、キューの深さ、Recorderやバックアップジョブの実行タイミングを確認します。症状がこれらの指標に追随し、競合するI/Oを取り除くと消えるなら、ストレージがより有力な診断結果になります。

サーバーの準備はできているのに経路が機能していないならネットワークが制限要因

ネットワークのボトルネックには、スループット、パケットロス、DNSの遅延、Wi-Fiの不安定さ、ファイアウォールポリシー、リモートサービスへの依存などがあります。Home AssistantのCPUがアイドル状態でローカルストレージが高速でも、1つのインテグレーションやクライアントがネットワーク待ちになることがあります。

まずサーバー上でローカルにテストし、次に同じLANから影響を受けているデバイスまたはクライアントをテストします。ローカルリクエストは高速なのに、特定のVLAN、Wi-Fiセグメント、DNS名、クラウド接続型インテグレーションだけが遅い場合は、その経路に絞って修正します。

ネットワーク使用率だけでは不十分です。インターフェースの負荷が低くても、名前解決、ルーティング、パケットロスが原因で障害が発生することがあります。一方、使用率が高くても、余裕がありパケットロスが少なければ正常に動作する場合があります。

変数を1つだけ変更し、症状が変化することを確認する

ZimaSpaceによるHome Assistantの制御経路におけるストレージ遅延の分析は、この手法のよい例です。あるコンポーネントがボトルネックになるのは、その処理時間が実際の制御遅延と一致する場合に限られます。

管理された変更によって元の症状が確実に改善したら、そこで止めます。これは単一の使用率の割合より強い証拠であり、間違った層を改善するための高額なアップグレードを防げます。