ディスク空き容量が不足してきた件 | そう備忘録

ディスク空き容量が不足してきた件

空き容量の不足

このブログのサーバー(AWS環境下のUbuntu)のディスクの空き容量が不足してきたので対応したときの備忘録。

尚、今回の記事では物理的なハードディスクを増やしたのでは無く不使用のパッケージ類を削除する事で容量を確保している。

環境

尚、当方の環境は以下の通り

サーバー

AWS(Amazon Web Services)のEC2( Elastic Compute Cloud)

OS

Ubuntu 16.04 LTS

CMS

WordPress 5.1.1(2019年4月8日現在)

ハードディスクサイズ

8GByte(OS込み)

当初お試しのつもりでAWSを立ち上げたのでOS込みで8GByteと元々それ程大きな容量を割り当てていなかった

AWSのディスク容量 8GByte

状況

何となく「動作がもっさりしているな」と感じ始めたのがここ数日、そしてこのサイトはWordPressのプラグインのJetPackで5分毎に状態を監視しているが1日に2回ダウンタイムのメールが届いていたのが一昨日。

ダウンは数分後に直ぐに復旧していたのだが、今にして思うとディスクの容量不足でレスポンスが遅くなってしまっていたのかも知れない(推測)

JetPackからのダウンタイムの連絡

そしてWordPressのプラグインのUpdraftPlusにて定期的にデータベース、イメージファイルのバックアップを取得していて、終了後に完了メールが届くのだが昨日のメールには「空き容量が非常に少ない」との警告が書かれていた。

またUpdraftPlusでのバックアップ先はクラウドストレージにしており空き容量を確認した所、十分に空き容量があったので恐らくバックアップファイルを作成する際に一時的にサーバー上にファイルを作成する時にサーバー上で容量不足に陥ったのだと推測された。

UpDraftPlusのバックアップ完了メールで警告

急いでssh(PuTTY)でサーバーに接続して、dfコマンドにて空き容量を確認してみた。

sudo df -h

df

ファイルシステムの全容量、使用済、使用可能、使用率、マウント位置を表示するコマンド

-h

サイズ表記にK、M、G等の単位を付ける(分かりやすくなる)

df -hで空き容量をチェック

/dev/xvda1の使用率が93%で残りが583MByteしか無い事が判明、至急何らかの対応が必要になった。

対応方針

基本的な対応方針は以下の順番とした。

  1. まずは不要なファイルを削除して当面の空き容量を増やす
  2. 次にAWSでディスクを割り当ててて全体のディスク容量を増やす

尚、今回は1.についての記事とする(2.については別記事とする)

不要なファイルの削除

現状の調査

どこのディレクトリの容量が大きいのかをduコマンドで調査する。

$ sudo du -sh /*

du

指定したファイルやディレクトリの使用容量を表示するコマンド

サブディレクトリも含めて計算するので、ディレクトリ配下の使用容量を算出する事ができる

-s

総計を表示する

このオプションを付けないとサブディレクトリまで表示されてしまう

-h

サイズ表記にK、M、G等の単位を付ける(dfと同様)

duコマンドで容量を調査

一部アクセス出来ないディレクトリがあったが、

/usr 3.4G
/var 2.2G

の2つのディレクトリ配下の容量が多いことが判明した。

ある意味予想通りだったが、それぞれ更に中を見ていく。

以下のコマンドで/var配下で容量の多いトップ5のディレクトリを表示する。

cd /var
sudo du -sm ./* | sort -rn | head -5

-s(duコマンド)

総計を表示する(前述)

-m(duコマンド)

M(メガ)単位で表示する

-hオプションだとそれそれK、M、Gの単位が付いてしまい単純に大きさを比較できないのでM(メガ)で単位を統一する

|

パイプライン

次のコマンドに前コマンドの出力結果を引き渡す

sort

並び替えを行う(デフォルトは昇順)

-r(sortコマンド)

降順でソートする

容量の大きい順に表示させたいので降順にする

-n(sortコマンド)

数字順に並べる

-nオプションをつけずに1、2、11をソートすると文字列としてソートするので1→11→2の順番になってしまう

-nオプションをつけることにより数字の大小順に並び替えてソートされる

head

先頭部分を表示する

-5(headコマンド)

先頭から5行を表示する

/varの中の容量の多い順

/www ・・・ 1.3 GByte
/lib ・・・・ 806 MByte
/cache ・・・ 70 MByte

の順番で容量を消費している事が判明した。

同様に/usr配下も調査する。

cd /usr
sudo du -sm ./* | sort -rn | head -5

/usrの中の容量の多い順

/src ・・・・ 2.6 GByte
/lib ・・・・ 356 MByte
/share ・・・ 251MByte

の順番で容量が多い事が判明した。

ファイルの削除

まずは上記結果に基づきそれぞれのディレクトリ内で不要なファイルをチマチマと削除を行った。

その後に以下のコマンドでインストール時のキャッシュをクリアした。

sudo apt-get clean

apt-get clean

apt-get Installで作成されたインストール用のキャッシュファイル(debパッケージ)をクリアする

続けて、一番効果が大きかったのがapt-get autoremoveコマンドによる依存関係の無い不要なパッケージの削除。

sudo apt-get autoremove

apt-get autoremove

不要になったパッケージを依存関係を考慮して自動的に削除してくれるコマンド

Pythonなど、このサーバーでは使用していないパッケージが削除された。

apt-get autoremoveコマンドの実行結果

結果

再度dfコマンドにてファイルシステムの状態を確認した所、4GByte空いていた。

またここ数日のもっさりとしたレスポンスも解消されていたのでやはり容量不足でもっさりとしていたのだと推測される。

不要ファイル削除後の空き容量

これだけ空いていれば、しばらくは大丈夫だが元々8GByteしかディスクを確保していないのでいずれまた容量が不足してくる。

次回は不要ファイルの削除と同時にAWS EC2にストレージを追加することにした。

souichirou

やった事を忘れない為の備忘録 同じような事をやりたい人の参考になればと思ってブログにしてます。 主にレゴ、AWS(Amazon Web Services)、WordPress、Deep Learning、RaspberryPiに関するブログを書いています。 仕事では工場に協働ロボットの導入や中小企業へのAI/IoT導入のアドバイザーをやっています。 2019年7月にJDLA(一般社団法人 日本デイープラーニング協会)Deep Learning for GENERALに合格しました。 質問は記事一番下にあるコメントかメニュー上部の問い合わせからお願いします。

おすすめ

6件のフィードバック

  1. 匿名 より:

    参考になりました。ありがとうございます。

  2. 匿名 より:

    とても参考になりました。
    ありがとうございます。

souichirou へ返信する コメントをキャンセル

名前、メール、サイト欄は任意です。
またメールアドレスは公開されません。