ローカル制御の品質が低下する前に、Home Assistantの同時タスク数を実際に制限するものは何ですか？

Home Assistantが「同時に処理できるタスク数はどのくらいか」という問いに、意味のある一つの答えはありません。10個の短い非同期タスクは、イベントループをブロックする1つの統合より負荷が小さい場合があります。一方で、キューに入った50個の自動化も、その大半の時間を独立したI/Oの待機に費やしているなら、問題にならないことがあります。

実用上の限界とは、作業を増やすことで重要な制御経路に繰り返し遅延が生じる地点です。イベントの処理待ち時間が長くなる、自動化キューが増加する、サービス呼び出しが目標のタイミングに間に合わない、あるいは共有CPU、メモリ、ストレージ、ネットワーク資源に負荷がかかる、といった状態です。したがって、同時実行性はタスク数の問題である前に、レイテンシーとキューの問題です。

Home Assistantの同時実行性はAsyncioイベントループから始まる

Home Assistant CoreはPython asyncioを中心に構築されています。コンポーネントはタスクとして処理をスケジュールし、協調的な非同期コードはI/Oを待つ間に処理を譲ります。これにより、統合ごとに1つのOSスレッドを割り当てることなく、他の処理も進行できます。

現在のHome Assistant開発者向けドキュメントでは、Coreは中央のイベントループを通じてコンポーネントのタスクをスケジュールし、タスクが待機中に適切に一時停止することに依存していると説明されています。つまり、「同時実行」とは、すべてのタスクがまったく同じ瞬間にCPU命令を実行するという意味ではありません。

実用的な同時実行性の分析でも、同じ区別が重要です。非同期タスクは経過時間上では重複して実行できますが、実際のイベントループ上の実行はawaitポイント間で逐次化されます。処理能力は、各タスクがループを占有する時間と、何を待機しているかによって決まります。

ブロッキング処理は一度に多数のタスクを劣化させる

最も深刻な同時実行性の障害は、「自動化が多すぎる」ことではない場合が多くあります。無関係な状態更新やコールバックを実行できなくなるほど長時間イベントループをブロックする、たった1つの処理が原因になることがあります。

Home Assistantは、イベントループ内のブロッキング処理は、呼び出しが続く間システム全体を停止させると明確に警告しています。これには、適切に処理されていないファイルI/O、ネットワークライブラリ、スリープ、統合内での重い同期処理などが含まれます。

この点により、処理能力テストの解釈も変わります。全体のCPU使用率が低いにもかかわらず、特定の統合を有効にするとローカル制御のレイテンシーが上昇する場合、問題はプロセッサー能力の不足ではなく、イベントループのブロックである可能性があります。

自動化モードが繰り返しトリガーを処理に変える方法を決める

自動化には、同時実行性に関する別のポリシー層もあります。ルールは2回目のトリガーを拒否することも、現在の実行を再開することも、処理をキューに入れることも、並列実行を作成することもできます。これらの選択は、正確性と必要なリソースの両方を変えます。

Home Assistantの現在の自動化モードに関するドキュメントでは、single、restart、queued、parallelの各モードと、キューまたは並列実行の最大数を設定できることが定義されています。queuedモードとparallelモードのデフォルトの最大値は10ですが、この設定値はプラットフォーム全体の処理能力を示すものではありません。

2秒待ってから通知を送信するドアセンサーの自動化と、5回のネットワーク呼び出しを行う照明の自動化は、同じ種類の処理ではありません。まず順序と正確性を基準に自動化モードを設定し、そのうえで生成されたキューや重複実行が制御レイテンシーに影響するかを確認してください。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

CPU使用率だけでなく、キューの増加とテールレイテンシーを測定する

重要なローカル自動化をレイテンシー測定の基準にします。トリガーの到着、自動化の開始、サービス呼び出し、物理デバイスの応答を記録し、繰り返しトリガー、ダッシュボードのクライアント数、バックグラウンド統合、周辺サービスなど、同時実行性に関する変数を一度に1つだけ増やします。

イベント駆動型の処理とアイドル状態のサーバー負荷に関するZimaSpaceの記事は、適切な基準を示しています。イベント駆動型システムは、必要なときだけ処理を起動するため効率的ですが、バーストが発生してもキューを継続的に滞留させずに処理しきるには、十分なスケジューリング能力とリソースの余裕が必要です。

中央値のレイテンシーと、通常実行時の最も遅い処理を確認します。平均CPU使用率が10%でも、短いバーストによって1秒間の停止が発生することがあります。キューが増え続ける、最大実行数の警告が繰り返し表示される、またはバースト終了後もテールレイテンシーが基準値に戻らない場合に、実用上の処理能力の境界が現れます。

Home Assistantの同時実行性とホストの競合を切り分ける

別のコンテナがCPU、メモリ、ストレージ、ネットワークを飽和させていても、Home Assistant自体は正しくスケジュール処理を行っている場合があります。この場合、共有ホストのリソース余力がすでに失われているため、自動化のmaxを増減しても問題は変わらない可能性があります。

周辺のワークロードを停止した状態で、同時実行性テストをもう一度実施します。イベントループのタイミングとローカル制御のレイテンシーがすぐに回復するなら、限界は共有ホストの処理能力の問題として扱います。回復しない場合は、Home Assistant内部のブロッキング処理、統合の動作、自動化キューの設計を調べます。

タスク数を公表するのではなく、停止条件を設定する

したがって、Home Assistantの処理能力は、同時実行タスク数の普遍的な数字ではなく、レイテンシー目標を設定してテストしたワークロードとして示すべきです。重要なのは、現在の統合構成とホストが、重要なローカル制御経路の期限を満たせなくなる前に、どの程度の重複処理を吸収できるかということです。