icewhale-files-backupが数GBのRAMを消費するまで増大し、ZimaOS 1.7.0でOOMキラーを繰り返し発動させる場合は、まずZimaOS 1.7.1以降に更新してください。 IceWhaleの1.7.1リリースノートには、特定のファイル操作シナリオでの異常なメモリ使用量や、バックアップの失敗・中断に関する問題を明示的に修正したと記載されています。
元のスレッドでは、1.7.0で深刻な回帰が発生したことが報告されています。メモリ使用量が約3.5GBから10GB超まで増加し、カーネルがBackupを強制終了すると、Restart=alwaysによってプロセスが復帰し、そのサイクルによってサーバーが不安定になりました。サービスをマスクするとループは停止しましたが、これは緊急時の回避策にすぎません。
OOMループを確認する
journalctl -k | grep -i -E 'oom|out of memory|killed process'
ps aux --sort=-%mem | head
free -hBackupプロセスが繰り返しメモリ使用量の最上位に戻る場合、再起動ループによってDockerやその他のサービスに必要なリソースが不足する可能性があります。
1.7.1以降に更新する
公式のZimaOS 1.7.1リリースノートには、異常なメモリ使用量や、失敗・中断する可能性があったバックアップタスクに関する修正が記載されています。
ZimaOS 1.7.0での緊急復旧
sudo systemctl stop icewhale-files-backup.service
sudo systemctl disable icewhale-files-backup.service
sudo systemctl mask icewhale-files-backup.service通常の停止や無効化だけでは、サービスの再起動ポリシーによる再起動を常に防げなかったため、マスクが必要でした。
マスクによる影響を理解する
マスクすると組み込みのBackupが無効になります。使用不能になったホストを更新またはデータ復旧まで一時的に安定させる場合にのみ使用してください。
更新後にマスクを解除する
sudo systemctl unmask icewhale-files-backup.service
sudo systemctl enable icewhale-files-backup.service
sudo systemctl start icewhale-files-backup.serviceその後、RAMとスワップを監視しながら、小規模で制御したバックアップを実行してください。
USBバックアップのワークロードが一般的な誘因だった
複数のユーザーが、USBバックアップ先で同様の挙動を報告しています。これはバグの再現に役立ちますが、原因がエンクロージャー自体にあったことを証明するものではありません。
バックアップの完全性を確認する
ソースと保存先のファイル数を比較し、復元テストを実行してください。バックアップ検証ガイドを活用すると、単一のジョブへの依存を減らせます。
メモリ不足によってDockerが影響を受けていないか確認する
スレッドでは、長時間にわたるメモリ圧迫によってDockerアプリケーションが利用できなくなったと報告されています。ホストが安定したら、大規模なバックアップワークロードを再開する前に、docker ps、Dockerデーモン、重要なコンテナを確認してください。
更新後は小規模なバックアップから始める
障害の原因となった数TB規模のジョブやUSBジョブを、すぐに再実行しないでください。まず小規模なテストタスクを作成し、10～20分間メモリを監視してから、ファイル数と合計サイズを段階的に増やしてください。これにより、修正済みサービスのメモリ使用量が適切な範囲に収まっているか確認しやすくなります。
バイト数と同じくらいファイル数も重要
数十万個の小さなファイルは、数個の大きなメディアファイルよりもはるかに多くのメタデータ処理を発生させる可能性があります。サポートへの報告には、合計バイト数とおおよそのファイル数の両方を含めてください。
テスト中は独立したバックアップ経路を維持する
組み込みのBackupが以前に不完全だったり不安定だったりした場合は、復元テストによって現在のZimaOSジョブが信頼できると確認できるまで、別のツールまたは保存先を使って、正常に動作する別のコピーを維持してください。
修正前後のログを保存する
更新前に、OOMメッセージ、メモリ使用量上位のプロセス、ZimaOSのバージョン、バックアップ先の種類を保存してください。その後、1.7.1以降で同じ制御されたワークロードを再実行し、メモリの増加量を比較します。これにより、「サーバーが安定しているように感じる」だけに頼らず、回帰が解消されたことを示す証拠を得られます。
修正済みリリースでもメモリが際限なく増加する場合は、タスクを停止し、修正前後の測定結果をサポートに提出してください。
FAQ
メモリリークは複数のユーザーによって確認されていますか？
はい。複数のユーザーが1.7.0で同じ挙動を報告しています。
1.7.1でこの種の問題は対処されましたか？
はい。公式の変更履歴には、この問題に直接関連するメモリおよびバックアップの修正が含まれています。
1.6.2に戻すべきですか？
これは1.7.1以前の一時的な回避策でした。現在のユーザーは、修正済みの安定版を優先してください。
修正が機能したかどうかは、どう確認できますか？
メモリ、スワップ、ログ、保存先の完全性を監視しながら、制御されたバックアップを実行してください。
