再現可能なワークロードでHome Assistantのリソース余力をベンチマークする方法

Home Assistantのパフォーマンスベンチマークは、同じワークロードを再現し、リソースグラフを見る前に「十分に高速」とは何かを定義している場合にのみ有用です。そうでなければ、CPU、メモリ、ストレージ、ネットワークの数値は、容量に関する結論を伴わない単なる観測結果になってしまいます。

これは、1台の遅いインストール環境をトラブルシューティングする場合とは異なります。ベンチマークでは、再現可能なベースラインを意図的に作成し、1つのワークロードの要素を増やして、選択した自動化、履歴クエリ、またはダッシュボードの応答が許容レイテンシの範囲を外れる前に、どれだけのリソース余裕が残っているかを特定します。

1つのワークロードと1つの合格基準を定義する

実際の家庭内ピークを代表するワークロードを選びます。たとえば、ローカルのモーション自動化、3つのアクティブなダッシュボード、通常のRecorder書き込み、バックアップを行わないバックグラウンド期間、固定された一連のインテグレーションなどです。Home Assistantのバージョン、ホストのハードウェア、ストレージ、データベース、クライアント、ネットワーク経路、テスト時間を記録します。

Home Assistantのシステム情報ビューには、インストール、ネットワーク、インテグレーション、リソースに関するコンテキストが表示されるため、パフォーマンス結果と併せて記録すべきです。環境の詳細がなければ、ある人の応答時間を別のマシンと意味のある形で比較することはできません。

次に、合格基準を定義します。照明の自動化では物理的な応答を1秒未満にする必要がある一方、5年間の履歴クエリは数秒かかっても許容できる場合があります。これらを1つの一般的な「Home Assistantの速度」スコアにまとめないでください。

すべての共有リソースで使用率、飽和度、エラーを確認する

平均使用率だけでは、停止条件として不十分です。ディスクは高負荷でも正常に動作する場合がありますし、CPUの平均使用率が控えめでも、短時間のバーストによってユーザーがレイテンシとして感じるキューが発生することがあります。

USEメソッドでは、各物理リソースまたは制約のあるリソースについて、使用率、飽和度、エラーを評価します。最も高い使用率グラフを選ぶのではなく、この考え方をCPU、メモリ容量、ストレージI/O、ネットワークインターフェースに適用します。

コンテナ化されたHome Assistantでは、cgroupの制限もリソースとして含めます。ホストのCPUに60%の余裕があっても、割り当てられたクォータに達したコンテナはスロットリングされる可能性があります。

プレッシャーメトリクスでリソース不足による時間の損失を確認する

LinuxのPressure Stall Information（PSI）は、レイテンシを重視した視点を加えます。CPU、メモリ、I/Oがどれだけ使われているかだけを尋ねるのではなく、PSIはリソース競合によってタスクが停止している時間の割合を測定します。

Linuxカーネルのドキュメントでは、CPU、メモリ、I/Oのプレッシャーを、競合によって実際に失われた時間として測定できると説明されています。これには、平均使用率が極端に高く見える前にレイテンシを悪化させる短いスパイクも含まれます。

そのため、PSIは共有ホームサーバーで役立ちます。別のコンテナが書き込みバーストを実行している間にI/Oプレッシャーが上昇し、Home Assistantのレイテンシが悪化するなら、「SSDの使用率は70%だった」という説明よりも、共有ストレージの競合を示す強い証拠になります。

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

実行ごとに増やすワークロードの要素は1つだけにする

ダッシュボードのユーザー数、自動化のトリガー、カメラストリーム、保持期間、バックアップトラフィックを同時に増やしてはいけません。その他の条件をすべて固定したまま、1つの変数だけを増やします。

有用な段階的テストには、1分あたりの自動化イベント数、同時接続するダッシュボード数、より広い履歴範囲、エンティティの更新数、または定義した隣接サービスの負荷を増やす方法があります。各段階の後は、ウォームキャッシュや起動時バーストの最初の10秒を収集するのではなく、システムが定常状態に達するのに十分な時間を待ちます。

ZimaSpaceによる共有ストレージのキュー競合とテールレイテンシに関する分析は、ワークロードをリソース経路に対応付ける必要がある理由を示しています。ストレージが重要になるのは、テスト対象のアクションがストレージに直接依存している場合、または同じI/Oキューを共有している場合だけです。

1つのリソースを変更し、結果が変化することを確認する

ベンチマークは、制御したリソースの変更によってレイテンシ曲線が変化したときに、診断的な意味を持ちます。負荷の高い隣接サービスをHome Assistantとは別のCPUに固定する、書き込みの多いジョブを一時停止する、テスト対象のcgroupメモリ制限を引き上げる、直接的なLAN経路を使用する、またはアプリデータをより低レイテンシのストレージに移す、といった方法があります。

同じワークロード段階で元のレイテンシのしきい値が改善したなら、そのリソースが余裕を制約していた可能性があります。何も変わらなければ、実験を元に戻し、変更を恒久的な設定にするのではなく、次の候補をテストします。

結果を容量の範囲として公開する

最終結果は、「このハードウェア、データベース、クライアント構成、バックグラウンドワークロードでは、選択した制御経路が段階Nまで目標範囲内に収まる」と読める形にします。この記述は再現可能です。「Home AssistantのCPU使用率はわずか20%」という記述には、再現可能な意味がありません。