NASアプリに影響を与えているかどうか、システムパーティションの容量がいっぱいか確認する方法

システムパーティションが満杯になると、大容量のデータプールに数テラバイトの空きがあってもNASアプリが停止することがあります。

アプリケーションはログ、データベース、一時ファイル、アップデート、コンテナレイヤー、ソケット、設定書き込みのためにローカルの空き領域を必要とします。どのマウントが満杯かを確認し、アプリのエラーを書き込み失敗に照らし合わせ、システムの消費元を特定し、その所有コンポーネントを通じて空き領域を回復してください。

システムパーティションが満杯のマウントであることを確認する

すべてのマウントされたファイルシステムを確認し、ルート、ブート、アプリケーション、コンテナ、データのパスをマッピングします。最初の作業は正確にどのマウントが満杯かを確認することです。データプールの空き容量はルートファイルシステムへの書き込みには使えません。

df -hでブロック容量を、df -iでファイルレコード数を確認します。パスは空きブロック数と空きinode数が別々の制限であり、どちらかが枯渇すると新規ファイルを拒否することがあります。

アプリの失敗を書き込み不足と照合する

「空き領域なし」「読み取り専用ファイルシステム」「ジャーナル失敗」「一時ファイル作成不可」などのメッセージをアプリ、データベース、コンテナ、システムログで確認します。アプリはメモリ上でウェブページを表示していても、バックグラウンドジョブ、アップロード、データベースコミットが失敗することがあります。

タイムスタンプを記録し、影響を受けたパスで無害な書き込みを試してください。証拠を保存するまでは広範囲な再起動は避けてください。すべてのアプリを再起動するとログが増え、最初のエラーが隠れ、次に失敗するサービスが変わることがあります。

ログ、コンテナレイヤー、inode、削除済みファイルを探す

トップレベルのシステムディレクトリの使用量を測定し、最も大きいものを掘り下げます。一般的な消費元はジャーナル、アプリログ、イメージレイヤー、ビルドキャッシュ、クラッシュダンプ、パッケージキャッシュ、サムネイル、一時ファイルです。削除前にアプリやコンテナマネージャのレポートを利用してください。

ディレクトリの合計がファイルシステム使用量を説明しない場合は、まだ開かれている削除済みファイルを確認します。inodeが満杯の場合は、小さなキャッシュやセッションファイルが大量にあるディレクトリを探します。回復後はログローテーションと保持制限を設定し、緊急削除の繰り返しを防ぎましょう。

安全に空き容量を確保し、回復を確認する

文書化されたクリーンアップ手順から始めます：ログのローテーションやバキューム、未使用のパッケージキャッシュの削除、未使用のコンテナアーティファクトのみのプルーニング、ツールを使った古いクラッシュダンプの削除。データベース、名前付きボリューム、アクティブなイメージ、設定はバックアップが確認できるまで保持してください。

ファイルシステムとinodeの使用状況を再確認し、影響を受けた依存チェーンのみを再起動して実際のアプリ書き込みをテストします。回復がまだ失敗する場合は、空き容量が原因と決めつけずに再起動後のサービス起動順序を調査してください。

よくある質問

NASのデータプールに空きがあるのにアプリが失敗するのはなぜ？

アプリはデータベース、ログ、一時ファイル、コンテナ状態をより小さいシステムパーティションに書き込むことがあります。容量はマウント間で自動的に共有されません。

ログファイルを削除すると問題が悪化することはありますか？

はい。実行中のプロセスが削除済みのログを開いたままにしている場合、パスは消えても空き容量は解放されません。正しいサービス手順でログをローテーションまたは切り詰めてください。

システムパーティションにはどのくらいの空き容量を確保すべきですか？

普遍的な割合はありません。アップデート、ログ、データベースメンテナンス、コンテナの成長、回復操作に十分な余裕を持ち、増加率と残量の両方でアラートを設定してください。