Home Assistantは読み取り時と書き込み時に異なる負荷を生成するのはなぜですか？

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

Why Does Home Assistant Generate Different Loads During Reads and Writes?

Home Assistantは、クエリがキャッシュされたページを再利用する一方、状態の永続化ではジャーナル、インデックス、永続ストレージが変更されるため、読み取り負荷と書き込み負荷が異なります。

履歴チャートを開くと、保存された多数の行を変更せずにスキャンできます。一方、ノイズの多い1つのセンサーは、1日を通して小さなトランザクションを発生させることがあります。前者ではシーケンシャル読み取り、データベースキャッシュ、クエリインデックスが有利に働き、後者では同期処理、ジャーナル更新、ファイルシステムメタデータ、フラッシュ書き込み増幅が加わります。そのため、どちらも同じRecorderデータベースを使用していても、グラフは異なります。

リアルタイムの状態変更は複数の書き込みを生み出す

Recorderは、選択された状態変更やイベント変更をデータベーストランザクションに変換します。論理的な行の挿入では、ファイルシステムとデバイスキャッシュが永続的な完了を確認する前に、インデックスやジャーナル、または先行書き込みログも更新されることがあります。

データベースと統計の解説では、短期的な状態保存と長期的な統計が分けて説明されており、Recorderのデータ構造が追記専用ファイル1つではなく、複数の関連構造にアクセスする理由が明確になります。

高頻度で変化するエンティティは、多数の小さな論理変更を生み出し、それらがまとめてコミットされることがあります。これは周期的なバーストとして現れる場合があります。データベースとストレージの各層が整合性を維持するため、物理的に書き込まれるバイト数はペイロードを上回ることがあります。

履歴の読み取りは範囲、選択性、キャッシュに左右される

現在の状態を検索する処理は小規模ですが、複数エンティティの履歴チャートでは、広い時間範囲をスキャンし、属性をデコードし、結果を集計してクライアントに送信することがあります。適切なインデックスとウォーム状態のデータベースページがあれば、これらの処理の多くを物理ストレージにアクセスせずに実行できます。

長時間にわたるパフォーマンス事例では、通常のリアルタイム利用にもかかわらず履歴アクセスが極端に遅くなっており、履歴クエリの負荷によって、現在の状態制御では発生しないクエリ経路の問題が明らかになる可能性が示されています。

関連するページがメモリに残っていると、繰り返し実行する読み取りは速くなることがよくあります。この利点は、再起動、メモリ不足、または異なる日付範囲の指定によって失われるため、ウォーム状態での1回のクエリだけではストレージ容量を信頼性高く測定できません。

書き込みコストはログ記録や周辺サービスによって増加する

一般的なホームサーバーで書き込みを行うのはHome Assistant Coreだけではありません。デバッグログ、アドオンのデータベース、バックアップ、カメラのスナップショット、コンテナログなどが同じデバイスを共有し、Recorderがコミットしようとするタイミングでキューイングを引き起こすことがあります。

フラッシュの摩耗を抑えた実践者は、ログや関連コンポーネントが書き込みサイクルを増やすことを確認しています。そのため、ボリューム全体の書き込み活動は、メインデータベースのプロセスだけでなく、ボリューム全体を対象にする必要があります。

プロセス単位のアトリビューションによって、アプリケーションの動作と共有ストレージの競合を切り分けられます。Recorderが静かな一方で別のコンテナが書き込みを占有している場合、エンティティの除外を変更しても観測された負荷は解決しません。

-15% OFF

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

Single board computer zimaboard2

メンテナンスによって通常のパターンが逆転することがある

期限切れの行の削除、インデックスの再構築、バキューム、または再パッキングでは、データベースの大部分を読み取り、書き換えることがあります。その間、クリーンアップと説明されるタスクが、通常の状態取り込みよりも重い読み取りと書き込みの両方を発生させる場合があります。

Recorderの設定に関する議論では、保持期間やパージの動作がデータベースメンテナンスと関連付けられています。そのため、毎日同じ時刻に定期的な負荷スパイクが発生する場合は、保持期間とパージの動作を確認することが重要です。

ボトルネックがCPU側のテンプレート評価、クライアント側の描画、またはネットワーク配信である場合、読み取りと書き込みによる説明は当てはまりません。症状と同時にストレージのカウンターも上昇していなければ、データベースは遅延の単なる隣接要因にすぎません。

1つの読み取り経路と1つの書き込み経路を比較する

固定した履歴クエリと、影響のない状態変更操作を1つ選びます。それぞれについて、コールドスタートと、その後のウォーム状態での繰り返し実行時に、リクエスト遅延、CPU使用率、データベース時間、ディスクスループット、IOPS、キュー深度、デバイス遅延を記録します。

関連する保持データの増加では、メタデータと履歴の増加によって負荷が変化する理由が説明されており、任意のベンチマークトラフィックではなく、保持されたデータに基づいて比較できます。

共分散によって制限要因を分類します。最初の読み取りが遅く、繰り返し実行が速い場合はキャッシュ局所性、範囲の拡大とともにクエリ時間が増える場合はスキャンコスト、書き込み遅延とキュー深度の上昇が同時に見られる場合は永続ストレージの競合が示唆されます。どのパターンにも当てはまらない場合は、別の層が原因です。ユーザーに見える遅延を2回再現する経路だけを最適化してください。