同時稼働するコンテナ向けにHome Assistantのデータベース接続を最適化する方法

Home Assistantのデータベース接続は、1つのプールを最大化するのではなく、すべてのコンテナ全体で合計接続数を予算化して最適化します。データベース管理とバックグラウンド処理のための余裕を残し、同時起動時と通常運用で最も書き込みが多い時間帯にRecorderを検証してください。

MariaDBまたはPostgreSQLを共有ホストで使用する場合、重要なのは、各サービスで使用可能な接続数に実行中のインスタンス数を掛けた値に、保守作業と緊急アクセス分を加えた合計です。アクティブ、アイドル、待機中、失敗した接続を、クエリレイテンシーやストレージ負荷と併せて測定します。SQLiteを使用している場合は、ここで止めてください。同じデータベースファイルを使うコンテナを増やすことは、接続プールのチューニングではありません。

データベースのトポロジーと現在の接続需要を確認する

データベースエンジンとバージョン、Home Assistant RecorderのURL、その他すべてのクライアントコンテナ、レプリカ数、設定済みプール、タイムアウト、リトライ動作、再起動ポリシーを記録します。アクティブなセッションを正しく識別できるよう、各サービスが専用のデータベースユーザーを使用していることを確認してください。

データベースの最大接続数、ユーザーおよび状態別の現在のセッション数、起動時と通常負荷時のピークセッション数、待機時間、クエリレイテンシー、CPU、メモリ、ストレージレイテンシーを測定します。接続数が多いのは、原因ではなく処理の遅さの症状である可能性があります。飽和したディスクにセッションを追加すると、通常は競合が増加します。

外部Home Assistantデータベースの信頼性に関するZimaSpaceガイドを使用して、同時実行数を調整する前に、バックアップ、スキーマ権限、エンジンのサポート状況、アップグレードの境界を確認してください。

すべてのコンテナの接続予算を作成する

データベース管理、監視、マイグレーション、バックアップ、データベースエンジン内部のタスク用に接続を確保します。残りのアプリケーション用予算は、搭載メモリやコピーした最大接続数ではなく、測定した同時処理量に応じて各サービスに配分します。

複数インスタンスのサービスに関する接続プールの指針では、重要な計算が明確に示されています。データベースはプールサイズにインスタンス数を掛けた接続数をサポートする必要があります。この考え方は広く適用できますが、Home Assistantとデータベースの各バージョンには、それぞれサポートされる設定が必要です。

まずは、上限を設けたプールとキューから始めます。需要が一時的にプール容量を超えた場合、無制限にセッションを開くより待機させる方が安全です。待ち時間がユーザーに見えるようになった場合は、プールを拡大する前にクエリとストレージのレイテンシーを調査してください。失敗が無期限にハングしないよう、接続タイムアウトと取得タイムアウトを明示的に設定します。

再起動、リトライ、アイドル接続を制御する

Home Assistant、ダッシュボード、分析、バックアップ、インポート処理が一斉に再接続やマイグレーションを行わないよう、コンテナの起動を分散させます。実際のデータベースの準備状態を確認するヘルスチェックを使用しますが、データベースの復旧中に接続ストームを発生させる短い間隔のリトライループは避けてください。

アイドル接続の存続時間と再利用・再作成の動作は、データベース、ドライバー、プロキシ、ネットワークのタイムアウトを考慮したうえで設定します。切断されたセッションをプールが長時間保持するとエラーの原因になり、接続を頻繁に作り直すプールは認証や初期化のオーバーヘッドを増加させます。一度に変更するタイムアウト層は1つだけにしてください。

接続プロキシを導入する場合は、テスト環境でトランザクションのセマンティクス、マイグレーション、プリペアドステートメント、Home Assistantとの互換性を確認します。プロキシは、低速クエリ、ロック、メモリ、ストレージに関する診断の代わりにはなりません。

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

同時実行数を増やす前にデータベース処理を減らす

Recorderの保持期間、高頻度エンティティの除外、パージ動作、データベースサイズ、低速クエリを確認します。Home Assistantのクエリが1つの接続を長時間保持している場合、セッションを追加するよりも、不要なデータを減らすかストレージレイテンシーを改善する方が、安全にスループットを向上できる可能性があります。

高負荷の分析や長期メトリクスをRecorderから分離するのは、新しいパイプラインの所有者と保持モデルが明確な場合だけにしてください。無関係なコンテナをHome Assistantのスキーマに接続したり、Recorderのテーブルに書き込ませたりしないでください。サポートされているAPIまたは独立したデータベースを使用します。

データベースサーバーの上限を引き上げる前に、接続あたりのメモリ、バッファ設定、ロック待機、ストレージレイテンシーを再確認します。サーバーは、復旧と管理に十分な余力を残しつつ、計画したピーク時にも応答性を維持する必要があります。

同時起動とRecorderのピーク負荷で検証する

計画した順序でデータベースとクライアントコンテナを再起動し、次に、安全に実施できる最も負荷の高い重複状態で再試行します。Home Assistantの起動、履歴クエリ、インポート、バックアップ、別サービスのピーク処理を同時に発生させます。接続数、取得待機時間、失敗、クエリレイテンシー、ロック、ホストのI/Oを監視してください。

合格する構成では、Home Assistantの操作と履歴表示が応答性を維持し、接続予算内に収まり、管理者アクセスを確保し、ピーク後に一時的なキューが解消されます。2回再起動し、次回の予定された保守時間帯も観察して、設定が維持されることを確認してください。

タイムアウト、「接続数が多すぎます」エラー、データベースのメモリ圧迫、Recorderのバックログが悪化した場合は、変更をロールバックします。単一の最大接続数ではなく、トポロジー、ユーザー別セッション数、プール設定、低速クエリの証拠、ストレージメトリクスを添えてエスカレーションしてください。