Home Assistantが予想以上に多くの一時データを保持する原因は何ですか？

エヴァ・ウォン

IceWhale author

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

What Causes Home Assistant to Retain More Temporary Data Than Expected? - Zima Store Online

Home Assistantは、バックアップ、データベース、ログ、更新、またはキャッシュの処理が、運用担当者が想定したクリーンアップのタイミングを超えて続くと、予想以上に多くの一時データを保持します。

一時的だからといって、必ずしも短期間しか存在せず、安全に削除できるとは限りません。失敗したアーカイブによってステージングファイルが残ることがあり、SQLiteはジャーナルや未使用ページを保持する場合があります。詳細なログを出力する統合機能によってログが増大したり、実行中のプロセスが、削除済みのストレージを再起動まで保持したりすることもあります。何かを削除する前に、所有パス、プロセス、作成時刻、実行中のジョブを確認してください。そうしないと、復旧処理を中断したり、状態を破損させたりするおそれがあります。

一時パスと保持されるアプリケーションデータを分ける

ディレクトリと所有者ごとに、データベースとジャーナル、バックアップのステージング、ログ、メディア変換、更新ファイルのダウンロード、アドオンのキャッシュ、コンテナレイヤー、オペレーティングシステムの一時領域に分類します。見かけ上のファイルサイズ、割り当て済みブロック、ファイルシステムの空き容量を比較してください。tempという名前のパスに実行中のトランザクションが含まれている場合があり、キャッシュディレクトリが意図的に再起動後も残ることもあります。

Home Assistantのインストールでは、設定された期間の詳細な履歴と、異なるルールで管理される長期統計が保持されるのが一般的です。この保持期間の違いは、古い詳細データが最終的に削除される予定であっても、データベースの増大を単に一時的なものと見なすべきではない理由を示しています。

データが文書化された保持ポリシーに属する場合は、ファイルを削除するのではなく、ポリシーを調整してください。完了または失敗したジョブに属し、アクティブな所有者がいない場合は、クリーンアップ候補になります。所有者が不明な場合は、特にデータベース、バックアップ、またはSupervisorが管理するパス内では、作業を停止すべき状態です。

失敗したジョブはステージングデータを残すことがある

バックアップ、更新、インポート、データベースメンテナンスでは、処理中に2つ目のコピーが作成されることがよくあります。通常、成功するとステージングデータの名前変更または削除が行われますが、中断、ディスク容量不足、ワーカーのクラッシュによって、そのクリーンアップが実行されない場合があります。その後、再試行を繰り返すことで、失敗したジョブの時刻と一致する複数世代のデータが作成されることがあります。

具体的な障害例は、失敗したバックアップファイルの削除に関する依頼に記録されています。この例では、バックアップの実行に失敗した結果、大容量のSupervisor一時ディレクトリが残りました。重要なのは、すべてのインストール環境で手動削除すべき普遍的なパスではなく、所有者とジョブの状態を確認することです。

バックアップ、復元、アップグレード、移行が実行中でないことを確認し、ジョブのエラーを保存したうえで、インストール形態に対応したサポート対象のクリーンアップ機構を使用してください。同じファイルが再び生成される場合は、まず失敗しているジョブまたは空き容量の境界条件を修正します。失敗ループを変えずに症状だけを削除しても、時計をリセットするだけです。

データベースファイルは行が消えても縮小しないことがある

Recorderのパージによって論理行が削除されても、データベースは再利用のために割り当て済みページを保持することがあります。ライトアヘッドログやジャーナルも、チェックポイントの条件が満たされるまで増大する場合があります。そのため、保持データが減った後もファイルサイズが大きいままになることがあり、手動で急に削除すると、無害なキャッシュを回収するどころか整合性を損なうおそれがあります。

Home Assistantで行われた、データベースのパージパターンに関する調査では、継続的な日次増加とスケジュールされたパージの時点が区別されています。また、短い観察期間では、想定どおりの動作を誤って判断する可能性があることも示されています。

少なくとも1回のクリーンアップサイクルにわたり、論理行の経過時間、データベースの状態、ジャーナルの状態、空き容量の推移を測定してください。検証済みのバックアップと十分な一時的空き容量がある場合に限り、サポート対象のデータベースメンテナンスを実行します。ジャーナルが収束しない、整合性チェックに失敗する、またはクリーンアップ中にRecorderが繰り返し再起動する場合は、エスカレーションしてください。

-15% OFF

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

Single board computer zimaboard2

安全な一時データの切り分けを行う

1時間間隔で2回、ストレージのスナップショットを取得し、パス、割り当て済みサイズ、変更時刻、所有プロセス、関連するジョブの状態を一覧にします。各項目を、アクティブ、ポリシーによる保持、失敗後に残った孤立データ、または不明に分類してください。比較中は新しいバックアップや更新が生成されないようにし、増加の原因を追跡できるようにします。

キャッシュと一時ストレージに関するZimaSpaceの手順では、所有関係を確認した後に使用できる、インストール環境レベルの制御方法を説明しています。

破棄可能であることが文書化され、かつプロセスによって開かれていない項目だけを削除し、その後で元のジョブを再実行して、成功とクリーンアップの両方を確認してください。2回のサイクルにわたって空き容量が安定すれば、合格です。所有者が不明なまま、またはデータベースの整合性が関係する場合は、回収を強行せず、データを保持してエスカレーションしてください。