コミュニティソリューション

ZimaOSのファイル機能がRAMを使いすぎる:OOMと再起動ループの解決策

A 1.6.2 system entered a 9–10 minute reboot loop after a 749,000-file copy as IceWhale file services consumed roughly 6GB RAM; masking them stabilized the host.

ZimaOS 1.6.2で大量のファイル操作後に再起動ループが発生し、icewhale-filesまたはicewhale-files-backupが数GBのRAMを消費している場合は、サービスを恒久的にマスクする前にZimaOS 1.7.1以降へ更新してください。 ZimaOS 1.7.1では、特定のファイル操作シナリオにおける異常なメモリ使用量が公式に修正されています。

報告元の内容は、障害の連鎖を明確に記録しているため、依然として有用です。約749,000個のファイルがコピーされ、RAM 7.5GBのマシン上でファイルサービスの合計使用量が約6GBまで増加し、スワップ使用率がほぼ100%に達した結果、サーバーが9~10分ごとに再起動しました。サービスをマスクするとこのループは止まりましたが、FilesウェブアプリとBackupサービスも無効になりました。

メモリ逼迫パターンを認識する

典型的な兆候:

  • RAMがほぼ枯渇している。
  • スワップの空きがほとんどない。
  • icewhale-files メモリ使用量の上位に入っている。
  • 非常に高いI/O待ち、またはシステムが停止したように見える状態。
  • 大量のファイル操作後に、ウォッチドッグによる再起動のような現象が繰り返される。

ステップ1:ZimaOS 1.7.1以降に更新する

公式のZimaOS 1.7.1リリースノートには、ファイル操作のシナリオにおける異常なメモリ使用量の修正が明記されています。

これが現在の主な解決策です。1.6.2の回避策を、2026年の通常構成にすべきではありません。

ステップ2:RAMとスワップを測定する

free -h
ps aux --sort=-%mem | head
swapon --show

何かを無効にする前に、ファイルサービスが実際に原因かどうかを確認してください。

ステップ3:最近の再起動を確認する

journalctl --list-boots

一定間隔で発生する現象かどうかを確認すると、ウォッチドッグまたはリセットによる動作とランダムな電源喪失を区別するのに役立ちます。

古い1.6.2システムでの緊急停止

更新を完了できるほどサーバーを長時間稼働させられない場合、報告元のユーザーは次の方法で安定させました。

sudo systemctl stop icewhale-files.service icewhale-files-backup.service
sudo systemctl mask icewhale-files.service icewhale-files-backup.service

これは緊急復旧のための手段です。重要な標準機能が無効になります。更新後はマスクを解除し、通常どおり現在のサービスをテストしてください。

復旧後にマスクを解除

sudo systemctl unmask icewhale-files.service icewhale-files-backup.service
sudo systemctl start icewhale-files.service icewhale-files-backup.service

システムを修正済みまたは現行のリリースに更新し、メモリの挙動を観測できるだけの安定性を確保してから、これを行ってください。

大きなファイル数と大きなファイルサイズは異なる

749,000個の小さなファイルは、67GBの動画1つよりもメタデータ処理やインデックス作成に大きな負荷をかける可能性があります。問題を再現または報告する際は、合計バイト数とファイル数の両方を含めてください。

NTFS/FUSEと多数のコンテナが負荷を増加させる

問題のマシンでは約38個のコンテナも稼働し、複数のNTFSボリュームを使用していました。 ntfs-3g。これらは状況を示す条件であり、実証済みの原因ではありません。観測されたメモリ増加がIceWhaleのファイルサービス内で発生していた場合、それらを根本原因だと決めつけないでください。

現在の最初の対策として、ランダムにMemoryMaxを追加しない

原文の著者はsystemdを提案しました MemoryMax= 製品改善として。現行バージョンでは、サービスを人為的に制限すると、ワークロードが正当にメモリを必要としている場合に、新たなインデックス作成やバックアップの失敗を招く可能性があります。

まず更新してから、測定してください。サービスの制限は、トレードオフを理解した場合にのみ適用してください。

小容量のシステムドライブにAppDataを保存しない

メモリスラッシングは、一時的に大量のI/Oを発生させることがあります。現在のZimaOSアプリストレージガイドでは、AppDataをメインストレージに移動することを推奨しています。

パフォーマンスのトラブルシューティングガイドでは、より幅広いリソースのチェック項目を紹介しています。

よくある質問

ZimaOS 1.7.1でこのメモリバグは修正されましたか?

特定のファイル操作シナリオにおける異常なメモリ使用量を正式に修正したもので、今回の障害パターンと直接重なります。

icewhale-filesを恒久的にマスクすべきですか?

いいえ。マスク化は緊急時の回避策であり、FilesとBackupの機能を無効にします。

なぜスワップによってサーバーの状態が悪化したのですか?

RAMが枯渇すると、アグレッシブなページングによって大量のディスクI/Oと長時間の停止が発生することがあります。特に、ファイルサービスがすでに大量のファイルをスキャンまたはコピーしている場合は顕著です。

それでも発生する場合、どのような証拠を収集すべきですか?

ZimaOSのバージョン、ファイル数、転送サイズ、RAM/スワップの状態、メモリ使用量の多いプロセス、マウント/ファイルシステムの種類、起動・再起動のタイムスタンプ。