Home Assistantが現在のホームサーバーでは手狭になったサイン

異常なインテグレーションとリソース競合を切り分けた後も、通常のピーク時のワークロードでサービスと復旧の目標を繰り返し達成できない場合に限り、Home Assistantがサーバーの処理能力を超えたと判断できます。

ダッシュボードの表示が遅い、再起動に時間がかかる、CPU使用率のグラフが高いというだけでは、原因を特定できません。1つのアドオン、データベースジョブ、ストレージ経路の障害が、ホストの性能不足に見えることもあります。通常の繁忙時間帯に、イベント発生から動作までの遅延、メモリの逼迫、ストレージの遅延、再起動後に使用可能になるまでの時間を記録しましょう。その後、疑わしい負荷を一度に1つずつ取り除き、同じテストを繰り返してから移行を計画します。

ホストを評価する前にサービス目標を設定する

家庭で重要な結果を2つか3つ選びましょう。ローカルオートメーションのイベント発生から動作までの遅延、再起動後にダッシュボードが使用可能になるまでの時間、通常最も忙しい時間帯に履歴の記録やバックアップが正常に完了するかどうかです。後の変更を同じ負荷と比較できるよう、テストのトリガー、ワークロード、許容できる結果を記録します。

最近の遅延事例では、ホスト全体の問題に見えたにもかかわらず、使われていないMatterサービスを削除すると動作が速くなりました。このアドオンの切り分け結果は、ハードウェアを原因とする前に、症状を再現可能なサービス目標と結び付ける必要があることを示しています。

PASSは、定義した負荷のもとでホストが目標を満たしていることを意味します。FAILは、1つ以上の結果が継続して目標に達していないことを意味し、さらに詳しく切り分ける必要がありますが、交換が必要だとはまだ判断できません。インターフェースの反応の良さだけに頼らず、生のタイムスタンプとリソースの記録を保管してください。

異常なワークロードを1つずつ取り除く

最近追加したものや、明らかに負荷が高いインテグレーション、カスタムコンポーネント、アドオン、バックアップ、インデックス作成ジョブ、共有サービスから始めましょう。一度に1項目だけ無効化または再スケジュールし、検証のために1回だけ再起動して、同じワークロードを再実行します。大幅な改善があれば、ワークロードが問題の原因です。ハードウェアを増強しても、問題が見えにくくなるだけかもしれません。

Home Assistantのホストが遅い場合、コミュニティでの診断では、メモリを保持したり、予想外にCPUを消費したりするアドオンやインテグレーションが、まず原因として疑われることがよくあります。問題のあるインテグレーションを切り分けるためのアドバイスを参考にすれば、ワークロードの異常な挙動と、プラットフォーム全体の容量不足を区別できます。

1つの項目を取り除くだけですべての目標を達成できるなら、ホストの移行を検討する前に、そのコンポーネントを修復または交換してください。1つの変更だけでは改善しない場合は、承認済みの構成に戻し、リソースごとのテストを続けてください。複数の無効化変更を重ねないでください。どの負荷が影響したのか特定できなくなります。

永続メモリとスケジューリングの負荷を調べる

同じ多忙な時間帯におけるピーク時の使用メモリ、スワップまたはメモリ回収の動作、メモリ不足イベント、CPU実行キュー、イベントからアクションまでの応答時間を測定します。CPU使用率の平均が中程度でも、短時間のスケジューリング遅延がオートメーションに影響することがあります。緩やかなメモリリークや、競合するコンテナの使用量増加の後に、メモリ不足が突然発生することもあります。

Home Assistantが頻繁に再起動するという報告を受けたら、まずRAMの使用量と最近追加したアドオンを調べることを推奨します。このメモリを優先する判別方法が有効なのは、容量不足による障害は稼働時間の長さだけでなく、リソース負荷と相関するはずだからです。

合格とは、繰り返しピークが発生しても負荷が一定範囲に収まり、レイテンシーが目標を満たすことです。不合格とは、サービスの目標を達成できないときに、スワップ、メモリ回収、プロセスの強制終了、または実行キューが増加することです。異常なワークロードを取り除いてもこの相関関係が崩れない場合に限り、そのホストを容量不足の候補とします。

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

ストレージとメンテナンス処理を分けてテストする

バックアップ、パージ、再パッケージ、メディアスキャン、または別のコンテナによる大量のI/Oを行わずにワークロードを1回実行し、次に通常のメンテナンス処理が重なる条件でも繰り返します。ブロックレイテンシー、空き容量、Recorderの滞留、履歴の応答時間、再起動後の準備完了までの時間を記録します。計算処理の容量と、低速または競合状態にあるストレージ経路を切り分けます。

ZimaSpaceの小型サーバー向けワークフローでは、ハードウェアについて結論を出す前に、測定したボトルネックを確認します。小型サーバーでHome Assistantを最適化する方法と同じ手順を適用し、ストレージ、メモリ、ワークロードの制約を見分けます。

メンテナンス処理の重複時にのみ失敗する場合は、大量処理のスケジュールを変更するか、分離して再テストします。ホストがほかの処理を行っていないときもストレージのレイテンシーが高い場合は、ハードウェア全体の容量不足と判断する前に、デバイスまたはファイルシステムを修復します。容量不足の根拠とするには、ストレージ経路が正常でも目標を達成できない必要があります。

再現性のある容量不足を3回確認する

同じ通常時のピークで同じ目標を3回の試行すべてで達成できず、各試行でボトルネックとなるリソースの負荷が増え、異常なワークロードを除外し、需要を元に戻せる方法で減らすとサービスが復旧する場合に限り、ホストの容量不足と判断します。さらに、移行先または交換先が、測定で特定したリソースの問題を解消できることも条件とします。

壊れたインテグレーションを1つ削除した後に合格したホストは、まだ性能の限界に達していません。任意のバックアップ時間帯にのみ失敗するホストなら、スケジュールの変更で解決できる場合があります。不可欠な負荷のもとで、スワップが繰り返し発生したり、I/Oがキューに滞留したり、ローカル操作への応答が遅れたりするホストは、移行を検討する根拠がより強いと言えます。

2回の再起動と最も負荷の高い通常時の処理重複期間で、対象の基準を満たしたら診断を終了します。条件を揃えた障害が3回続き、復旧時間の基準も満たせない場合は、移行計画に進みます。新しい環境で同一のワークロードと復元テストに合格するまで、現在のホストをロールバック用として維持します。