メインコンテンツへスキップ

ディスク逼迫の対処について

🌱 はじめに

本記事では、BookStackを使っているUbuntuサーバーで、ディスク容量が急に逼迫した際の調査・原因究明・対処までの流れをまとめます。df と du の差異、lsof を用いた調査方法、そして「削除済みだが解放されないファイル」の扱いについて実例とともに解説します。

📏 ディスク逼迫に気づいたきっかけ

BookStackを使っているときに、df コマンドで / の使用量が 15G / 19G (78%) と表示されていました。しかし、Webアプリやデータベースの保存ディレクトリを調べても数百MB程度しか使っていませんでした。この不一致から、目に見えない部分で容量を使っている可能性に気づきました。

🔍 df と du の違い

  • df -h / はファイルシステム全体の使用状況を表示します。

  • du -h --max-depth=1 / はファイル・ディレクトリごとのサイズ合計を表示します。

削除されたファイルでも、開いているプロセスがあると df では容量を消費し続け、du には表示されなくなります。

🕵️ 隠れた容量の調査：lsof の活用

以下のコマンドで、「削除されたのに開かれているファイル」を特定できます：

sudo lsof | grep deleted

この出力により、MariaDBやApacheが /tmp に作成し、削除されたファイルを開いたまま保持していることが分かりました。

原因を突き止める鍵は lsof の活用でした！

🛠 実際の解決方法

こうした「削除されたが開いたままのファイル」を完全に消すには、保持しているプロセスを終了させる必要があります。方法は以下の通りです：

  • Apache と MariaDB を個別に再起動：

sudo systemctl restart apache2
sudo systemctl restart mariadb

  • またはサーバーごと再起動：

sudo reboot

🎉 解決後の状況確認

再起動後に df -h を再度確認すると、使用量は以下のように改善されていました：

Filesystem      Size  Used Avail Use% Mounted on
/dev/root        20G  4.2G   16G  22% /

見えなかった約10GB以上の使用領域が無事解放され、空き容量が大幅に回復しました！

🤔 再起動後にも deleted が出る理由

再起動直後に lsof | grep deleted を実行すると、再び deleted 表示が出ることがあります。これは、ApacheやPHPが起動時に一時ファイルを作成してすぐ削除する、という正常な動作によるものです。

サイズが 0B の deleted ファイルは無視して問題ありません。問題なのは、巨大なファイルが deleted のまま開かれっぱなしになっているケースです。

🛡 再発防止のためのポイント

  • 定期的に df -h と lsof | grep deleted を確認

  • /tmp の使用状況を意識して監視

  • 長期間サーバを稼働し続けるなら、月に一度程度のサービス再起動がおすすめ

📚 おわりに

Linuxサーバーでは、削除したファイルがすぐには解放されないという仕様により、見えないディスク圧迫が発生することがあります。今回のように df と du の差を手がかりにし、lsof で原因を調査するという流れを理解しておけば、同様のトラブルにも素早く対応できます。


上に戻る