ファイルシステムのスナップショット作成中にNASのAIワークロードが停止するのはなぜですか?

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

NASのAIワークロードは、スナップショットの作成中に一時停止することがあります。これは、一貫性のためのバリアとコピーオンライトのメタデータが、フォアグラウンドの読み取り、書き込み、メモリ負荷と短時間競合するためです。

埋め込み処理は通常どおりファイルをストリーミングできていても、スケジュールされたスナップショットによってダッシュボードが数秒間フリーズしたように見えることがあります。スナップショットの作成時にコピーされるユーザーデータが少なくても、一貫したファイルシステムの時点を確立し、メタデータを更新する必要があります。ダーティ書き込み、データベースのチェックポイント、コピーオンライトによる割り当て、デバイスのキュー深度、スナップショット数、共有メモリによって、その処理が見えないまま済むか、AIパイプラインにまで影響するかが決まります。

スナップショットでは一貫した順序付けポイントを確立する必要がある

ファイルシステムのスナップショットは、1つの論理的な境界より前にコミットされたすべての変更を表し、それより後の変更を除外します。この境界に到達するには、大量のファイルデータをコピーしない場合でも、トランザクションの直列化、メタデータロック、ジャーナルのコミット、または書き込み関連のシステムコールの短時間の停止が必要になることがあります。

スナップショットの停止時間の測定では、スナップショット全体の所要時間と、変更を行うシステムコールが停止する短い時間を分けて考えます。この違いにより、スナップショットの実行自体は数秒かかっても、ユーザーに見える一時停止は、はるかに短い一貫性バリアの周辺に集中する理由が分かります。

AIの読み取り処理も、同じ時点でメタデータデータベースのチェックポイントが実行されたり、ファイルとインデックスの状態を同期させるためにアプリケーションが取り込みを一時停止したりすると、間接的に停止することがあります。このアプリケーションレベルの静止状態は、ファイルシステムのスナップショット自体とは別のものであり、個別に時間を測定する必要があります。

コピーオンライトではコストが後続の書き込みに移る

スナップショットの後、既存ブロックを初めて上書きすると、コピーオンライトによって古いバージョンが保持されることがあります。割り当て、参照カウントの更新、追加のメタデータI/Oにより、継続中の書き込みコストが増加します。特に、インデクサーが多数の小さな一時ファイルやデータベースページを生成する場合に顕著です。

コピーオンライトの同期増幅では、コピーオンライト仮想ディスクによって同期処理が大幅に増加し、評価された形式の1つでは3倍を超える同期処理が発生したことが示されています。この結果は、一貫性のためのメタデータが、アプリケーションデータの変更量を超えてレイテンシを増幅する可能性を示しています。

そのため、スナップショットのコマンド自体は短時間で完了しても、その後にAIジョブが遅くなることがあります。頻繁なチェックポイント書き込み、ベクトルセグメントの作成、サムネイルの更新は、読み取り専用の推論とは異なるCOWワークロードを生み出します。したがって、1つのスナップショットオーバーヘッドの数値で、すべてのNAS AIタスクを表すことはできません。

共有キューと保持処理によってオーバーヘッドが停止に変わる

スナップショットの削除、レプリケーション、チェックサム計算、ブロックの回収では、一貫性ポイントの後にバックグラウンドI/Oが発生することがあります。フォアグラウンドのAI読み取りが同じディスク、コントローラー、メモリキャッシュ、またはCPUの圧縮処理経路を共有している場合、平均スループットが許容範囲に見えても、キューイングレイテンシは上昇する可能性があります。

スナップショットのクリーニング負荷では、長期間保持されるコピーオンライトスナップショットを分析し、表現方法、クリーニング速度、断片化が、処理を中断しない運用にどのような影響を与えるかを示しています。バックグラウンドの排出処理が流入する変更に追いつけない場合、最終的にフォアグラウンドのコミットが空き容量を待つことになります。この違いは、その後の家庭内環境でのテストでも確認できます。

問題の境界となるのは、時間的な一致を証拠として扱うことです。スケジュールされたウイルススキャン、バックアップのアップロード、データベースのコンパクション、RAMの回収が同時に始まることもあります。ブロックレイテンシ、キュー深度、スナップショットイベント、アプリケーションのチェックポイントが1つのタイムライン上で一致した後にのみ、その一時停止を原因に帰属させてください。

スナップショットのバリアとその後の影響を測定する

スナップショットなし、スナップショット1つ、通常の保持スケジュールという条件で、固定した埋め込み処理または画像インデックス作成ワークロードを再生します。スナップショットの開始と完了、アプリケーションの一時停止時間、ファイルシステムのトランザクションレイテンシ、ディスクキュー深度、読み取りと書き込みのp95レイテンシ、ダーティメモリ、COWバイト数、クリーニング処理を記録します。

ローカルAIのバックプレッシャーと競合パターンを比較し、スナップショットの作成、保持データの削除、バックアップ転送を別々のテスト時間帯に配置します。読み取り専用の推論と書き込み負荷の高いインデックス作成についても繰り返しテストしてください。コピーオンライトとの相互作用が根本的に異なるためです。

制御された負荷の下で、スナップショットイベントが再現性のあるレイテンシの段差を引き起こす場合にのみ、スケジュールを変更します。一貫性バリアが短くても、スナップショット後の書き込みが遅い場合は、復旧可能なスナップショットを完全に無効にするのではなく、保持設定とバックグラウンドI/Oを個別に調整してください。

テック&AIハブ

もっと読む

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.