システムパーティションの容量不足がNASアプリに影響しているか確認する方法

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

アプリケーションは、ログ、データベース、一時ファイル、更新、コンテナレイヤー、ソケット、設定の書き込みにローカル領域を必要とします。どのマウントが容量不足かを確認し、アプリのエラーと書き込み失敗を照合して、システム上の容量を消費しているものを特定し、それを管理するコンポーネントを通じて領域を確保します。

システムパーティションが容量不足のマウントか確認する

マウントされているファイルシステムをすべて確認し、ルート、ブート、アプリケーション、コンテナ、データの各パスを特定します。最初に行うべきなのは容量が不足しているマウントを正確に確認することです。データプールに空きがあっても、ルートファイルシステム宛ての書き込みには使えません。

ブロック容量にはdf -hを、ファイルレコード数にはdf -iを使います。空きブロックと空きinodeは別々に制限されているため、どちらか一方が枯渇すると、新しいファイルを作成できないことがあります。

アプリの障害と書き込み領域の不足を照合する

アプリ、データベース、コンテナ、システムの各ログを確認し、「no space left」、読み取り専用ファイルシステム、ジャーナルの失敗、一時ファイルを作成できないといったエラーがないか調べます。アプリはメモリからウェブページを表示し続けていても、バックグラウンドジョブ、アップロード、データベースへのコミットが失敗することがあります。

時刻を記録し、影響を受けているパスで無害な書き込みを1回テストします。証拠を保存するまでは、広範囲な再起動を避けてください。すべてのアプリを再起動するとログが増え、最初のエラーが分かりにくくなり、次に障害が発生するサービスが変わる可能性があります。

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

システムの最上位ディレクトリの容量を測り、最も大きな項目をさらに調べてください。容量を消費しやすいものには、ジャーナル、アプリケーションログ、イメージレイヤー、ビルドキャッシュ、クラッシュダンプ、パッケージキャッシュ、サムネイル、一時ファイルなどがあります。内容の分かりにくいデータディレクトリを削除する前に、アプリやコンテナ管理ツールのレポートを確認してください。

ディレクトリごとの合計容量でファイルシステムの使用量を説明できない場合は、削除済みのファイルが開かれたままになっていないか確認してください。inodeが不足している場合は、小さなキャッシュファイルやセッションファイルが大量にあるディレクトリを探します。復旧後は、応急的な削除を繰り返すのではなく、ログのローテーションと保持期間の上限を設定してください。

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

まず、手順が文書化されている方法でクリーンアップしてください。ログをローテーションまたはvacuumし、不要だと確認できたパッケージキャッシュを削除し、未使用のコンテナ関連データだけを整理して、古いクラッシュダンプは専用ツールで削除します。検証済みのバックアップができるまでは、データベース、名前付きボリューム、使用中のイメージ、設定を残してください。

ファイルシステムとinodeの使用状況を再確認し、影響を受けている依存関係のチェーンだけを再起動して、実際にアプリから書き込みを試してください。それでも復旧しない場合は、容量が原因だと決めつけずに、再起動後のサービスの起動順序を調べてください。

よくある質問

NASのデータプールに空きがあるのに、アプリが動作しないのはなぜですか？

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

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

はい。実行中のプロセスが削除済みのログファイルを開いたままにしていると、パスが消えても容量は占有されたままです。適切なサービスの手順に従って、ログをローテーションまたは切り詰めてください。

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

一律の割合はありません。アップデート、ログ、データベースのメンテナンス、コンテナの増加、復旧作業に備えて十分な余裕を確保し、増加率と残り容量の両方に対してアラートを設定してください。