WebDAV

rclone でローカルファイルを OpenList の WebDAV インターフェース経由でクォークのクラウドドライブにアップロードすると、OpenList のメモリ使用量が明らかに増加し、コンテナ OOM を発生させるすることもあります。調査の結果、重要なのは、クォークドライバーがアップロード前にファイル全体をキャッシュすることと、コンテナの統計値にファイルページキャッシュが含まれていることでした。 本稿では、OpenList v4.2.7、通常のクォークドライバー、Docker、cgroup v2 を対象として分析します。 다른ドライバーやその他のバージョンを使用する場合は、実装を再確認する必要があります。 クォークのアップロードでキャッシュが必要な理由 OpenList の WebDAV エントリーポイントは HTTP リクエストボディをファイルストリームにラップし、対象のストレージドライバーに渡します。この処理自体は、ファイル全体を一度にメモリへ読み込むものではありません。 しかし、通常のクォークドライバーはまずファイルの MD5 と SHA1 を取得します。WebDAV アップロード経路では、ファイルオブジェクトにこの 2 つのハッシュ値が提供されないため、ドライバーは次を呼び出します。 stream.CacheFullAndWriter(&up, io.MultiWriter(writers...)) この呼び出しは、ハッシュを計算する一方でファイル全体をキャッシュします。続いて、ドライバーはクォークに事前アップロードとハッシュの要求を送信します。即時アップロードができない場合は、キャッシュからデータを読み出し、分割してアップロードします。 ハッシュの計算にはごく少量のメモリしか必要ありませんが、実際に大きな領域を占めるのは、後から読み戻すために保持されるファイル内容だからです。 クォークが分割アップロードに対応していても、先ほどのファイル全体キャッシュが存在しないことを意味しません。 v4.2.7 の HybridCache には、メモリとファイルという 2 種類のバックエンドがあります。メモリが許可されている場合、キャッシュの拡張を試み、割り当てが制限された後でファイルに切り替えます。そのうち一部は匿名 mmap によって管理されています。そのため、Go の GC パラメータを調整するだけでは、すべてのキャッシュ使用量を制約することはできません。 rclone の --transfers は同時に転送されるファイル数を制御します。2 つのファイルを並行してアップロードすると、ファイル全体のキャッシュが 2 つ同時に存在する可能性があります。rclone 自身の --buffer-size を小さくしても、OpenList プロセス内のこの部分のキャッシュを直接制限することはできません。 一時ディレクトリがあってもメモリを消費する理由 たとえば次のとおりです。 "temp_dir": "data/temp" これは一時ファイルの保存場所を指定するだけで、毎回キャッシュをディスクへ書き込むことを強制するものではありません。この相対パスの実際の場所は、OpenList の作業ディレクトリと Docker のマウントを組み合わせて判断する必要があります。 さらに、v4.2.7 のキャッシュ拡張チェックではシステム全体の空きメモリ統計を使用しますが、このチェックではコンテナの memory.max と memory.current を直接読み取りません。そのため、ホストに空きメモリが残っていても、コンテナはまず自分自身のメモリ上限に達する可能性があります。 ディスク上の一時ファイルを使用するように変更 まずアップロードを停止し、設定をバックアップしてください。config.json のトップレベルに次を設定します。 ...