コードロード

エラー討伐

【AWS】No space left on deviceサーバーの容量不足エラーのときの対処法

RailsアプリをAWSにデプロイしようとしたら詰まって2日間格闘した。

bundle exec cap production deploy しようとしたら、 No space left on device とエラーが出て、コマンド操作もできない、タブキーで予測変換もできないという状況になった。

原因はサーバー内の容量不足。

結論

不要なフォルダ/ファイルを削除して容量をこじ開ける

どうやら bundle exec cap production deploy したときに、releases配下に履歴がどんどん保存されていくらしく、それが容量を圧迫しているよう。

[サーバー上のアプリディレクトリ内]$ df -i
ファイルシス   Iノード  I使用  I残り I使用% マウント位置
devtmpfs        123170    284 122886     1% /dev
tmpfs           125862      2 125860     1% /dev/shm
tmpfs           125862    417 125445     1% /run
tmpfs           125862     16 125846     1% /sys/fs/cgroup
/dev/xvda1      658984 658938     46   100% /
tmpfs           125862      1 125861     1% /run/user/1001

[サーバー上のアプリディレクトリ内]$ df -h
ファイルシス   サイズ  使用  残り 使用% マウント位置
devtmpfs         482M     0  482M    0% /dev
tmpfs            492M     0  492M    0% /dev/shm
tmpfs            492M   13M  479M    3% /run
tmpfs            492M     0  492M    0% /sys/fs/cgroup
/dev/xvda1        12G   12G   20K  100% /
tmpfs             99M     0   99M    0% /run/user/1001

releases配下のフォルダ一つ一つに、更新に失敗した分も履歴としてすべてのフォルダが保存されてしますので、そりゃすぐ容量いっぱいになるわけだ。

[サーバー上のアプリディレクトリ内]$ ls releases/
20210406141744  20210407111547  20210408000028  20210408084345  20210409205101  20210409222600  20210410020742  20210410022814  20210410042928  20210410081637  20210410233758
20210406143525  20210407225211  20210408000747  20210408145208  20210409211526  20210409224033  20210410021010  20210410023120  20210410045543  20210410081957  20210410234323
20210406224534  20210407225657  20210408003409  20210408150303  20210409212133  20210409231007  20210410021532  20210410023823  20210410050339  20210410082431  20210411000011
20210407095130  20210407233212  20210408004714  20210409121244  20210409221946  20210410020046  20210410022147  20210410024951  20210410062726  20210410230330  20210411000424

[サーバー上のアプリディレクトリ内]$ ls releases/20210411000424
Capfile  Gemfile.lock  README.md  Rakefile  babel.config.js  config     db   log           package.json       public  storage  vendor          yarn.lock
Gemfile  Procfile      REVISION   app       bin              config.ru  lib  node_modules  postcss.config.js  spec    tmp      yarn-error.log

必ず、下記のコマンドで有効になっているrelesesのバージョンがないかどうか確認すること!削除してもいいのは、下記のコマンドででてきたフォルダ以外のフォルダ!

[サーバー上のアプリディレクトリ内]$ vi revisions.log

下記は、削除しても問題ないので、このように削除。

[サーバー上のアプリディレクトリ内]$ rm -rf releases/*

すると、容量に空きができる

[サーバー上のアプリディレクトリ内r]$ df -i
ファイルシス   Iノード  I使用   I残り I使用% マウント位置
devtmpfs        123170    284  122886     1% /dev
tmpfs           125862      2  125860     1% /dev/shm
tmpfs           125862    427  125435     1% /run
tmpfs           125862     16  125846     1% /sys/fs/cgroup
/dev/xvda1     6290416 251321 6039095     4% /
tmpfs           125862      1  125861     1% /run/user/1001

[サーバー上のアプリディレクトリ内]$ df -h
ファイルシス   サイズ  使用  残り 使用% マウント位置
devtmpfs         482M     0  482M    0% /dev
tmpfs            492M     0  492M    0% /dev/shm
tmpfs            492M   13M  479M    3% /run
tmpfs            492M     0  492M    0% /sys/fs/cgroup
/dev/xvda1        12G  8.1G  3.9G   68% /
tmpfs             99M     0   99M    0% /run/user/1001

どうするか

下記の記事通りにERBを拡張すればいい

無料枠は30GBまで。

これ以上やると、起動時間単位で料金が発生するから気をつけること。

qiita.com

記事内の、この部分だけ訂正。

× $ sudo resize2fs /dev/xvda1
◯ $ sudo xfs_growfs /dev/xvda1

調べていくと、CentOS 7 からデフォルトになっているXFSではresize2fsは利用できないということ。 XFSではresize2fs の代わりに xfs_growfs を使えばOK

qiita.com

teratail.com

手順

EC2の使用量をチェック

$ df -h
ファイルシス   サイズ  使用  残り 使用% マウント位置
devtmpfs         482M     0  482M    0% /dev
tmpfs            492M     0  492M    0% /dev/shm
tmpfs            492M  444K  492M    1% /run
tmpfs            492M     0  492M    0% /sys/fs/cgroup
/dev/xvda1       8.0G  8.0G   20K  100% /
tmpfs             99M     0   99M    0% /run/user/1001

$ df -i
ファイルシス   Iノード  I使用  I残り I使用% マウント位置
devtmpfs        123170    284 122886     1% /dev
tmpfs           125862      2 125860     1% /dev/shm
tmpfs           125862    363 125499     1% /run
tmpfs           125862     16 125846     1% /sys/fs/cgroup
/dev/xvda1      262824 262720    104   100% /
tmpfs           125862      1 125861     1% /run/user/1001

100%でぱんぱん・・・

この100%の部分「/dev/xvda1 」を拡張してあげることで、 No space left on device を回避することができる。

そもそも No space left on device を回避する方法として、種類は2種類ある。

  1. 容量を拡張する
  2. いらないファイルを削除する

8GBになってるからこれを拡張する。

[サーバー]$ lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0   8G  0 disk 
└─xvda1 202:1    0   8G  0 part /

ボリュームの容量を変更

AWSのERBボリュームの変更から下記のように変更。

(変更したいERBを選択した状態で、アクションをクリックすると「ボリュームの変更」が現れるはず)

自分の場合は。8GBから12GBへ変更。 確認してみる。

$ lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  12G  0 disk 
└─xvda1 202:1    0   8G  0 part /

お!ちゃんと12GBになってる!

ただ、全体の容量が増えただけで、本当に増えて欲しい xvda1 の容量は8GBのまま・・・

下記のコマンドで xvda1 をリサイズ!、、しようと思ったけど、このコマンドを行うときに生成されるファイルを置くスペースすらない模様。

$ sudo growpart /dev/xvda 1
failed [sfd_list:1] sfdisk --list --unit=S /dev/xvda
FAILED: failed: sfdisk --list /dev/xvda


適当にいらないファイルを消してあげて、容量をこじ開ける。

自分は下記のように対処しました。

[サーバー上のアプリディレクトリ内]$ ls tmp/cache/bootsnap-compile-cache
00  06  0c  12  18  1e  24  2a  30  36  3c  42  48  4e  54  5a  60  66  6c  72  78  7e  84  8a  90  96  9c  a2  a8  ae  b4  ba  c0  c6  cc  d2  d8  de  e4  ea  f0  f6  fc
01  07  0d  13  19  1f  25  2b  31  37  3d  43  49  4f  55  5b  61  67  6d  73  79  7f  85  8b  91  97  9d  a3  a9  af  b5  bb  c1  c7  cd  d3  d9  df  e5  eb  f1  f7  fd
02  08  0e  14  1a  20  26  2c  32  38  3e  44  4a  50  56  5c  62  68  6e  74  7a  80  86  8c  92  98  9e  a4  aa  b0  b6  bc  c2  c8  ce  d4  da  e0  e6  ec  f2  f8  fe
03  09  0f  15  1b  21  27  2d  33  39  3f  45  4b  51  57  5d  63  69  6f  75  7b  81  87  8d  93  99  9f  a5  ab  b1  b7  bd  c3  c9  cf  d5  db  e1  e7  ed  f3  f9  ff
04  0a  10  16  1c  22  28  2e  34  3a  40  46  4c  52  58  5e  64  6a  70  76  7c  82  88  8e  94  9a  a0  a6  ac  b2  b8  be  c4  ca  d0  d6  dc  e2  e8  ee  f4  fa
05  0b  11  17  1d  23  29  2f  35  3b  41  47  4d  53  59  5f  65  6b  71  77  7d  83  89  8f  95  9b  a1  a7  ad  b3  b9  bf  c5  cb  d1  d7  dd  e3  e9  ef  f5  fb

[ryu@ip-10-0-0-226 best_gifter]$ rm -rf tmp/cache/bootsnap-compile-cache/*

[ryu@ip-10-0-0-226 best_gifter]$ ls tmp/cache/bootsnap-compile-cache

[ryu@ip-10-0-0-226 best_gifter]$ df -i
ファイルシス   Iノード  I使用  I残り I使用% マウント位置
devtmpfs        123170    284 122886     1% /dev
tmpfs           125862      2 125860     1% /dev/shm
tmpfs           125862    367 125495     1% /run
tmpfs           125862     16 125846     1% /sys/fs/cgroup
/dev/xvda1      301328 267819  33509    89% /
tmpfs           125862      1 125861     1% /run/user/1001

再度、さっきのコマンド!できた!

$ sudo growpart /dev/xvda 1
CHANGED: partition=1 start=4096 old: size=16773087 end=16777183 new: size=25161695 end=25165791

$ lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  12G  0 disk 
└─xvda1 202:1    0  12G  0 part /


ファイルシステムの拡張

あれ?拡張したはずなのに、反映されていない。

$ df -h
ファイルシス   サイズ  使用  残り 使用% マウント位置
devtmpfs         482M     0  482M    0% /dev
tmpfs            492M     0  492M    0% /dev/shm
tmpfs            492M  6.6M  486M    2% /run
tmpfs            492M     0  492M    0% /sys/fs/cgroup
/dev/xvda1       8.0G  8.0G   16M  100% /
tmpfs             99M     0   99M    0% /run/user/1001

$ df -i
ファイルシス   Iノード  I使用  I残り I使用% マウント位置
devtmpfs        123170    284 122886     1% /dev
tmpfs           125862      2 125860     1% /dev/shm
tmpfs           125862    367 125495     1% /run
tmpfs           125862     16 125846     1% /sys/fs/cgroup
/dev/xvda1      301448 267819  33629    89% /
tmpfs           125862      1 125861     1% /run/user/1001

ファイルシステムも拡張する必要があり、リサイズしないといけないらしい。

$ sudo xfs_growfs /dev/xvda1
meta-data=/dev/xvda1             isize=512    agcount=4, agsize=524159 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1 spinodes=0
data     =                       bsize=4096   blocks=2096635, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal               bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
data blocks changed from 2096635 to 3145211

これでよし!!

一応確認。OK

$ lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  12G  0 disk 
└─xvda1 202:1    0  12G  0 part /

$ df -h
ファイルシス   サイズ  使用  残り 使用% マウント位置
devtmpfs         482M     0  482M    0% /dev
tmpfs            492M     0  492M    0% /dev/shm
tmpfs            492M  6.6M  486M    2% /run
tmpfs            492M     0  492M    0% /sys/fs/cgroup
/dev/xvda1        12G  8.0G  4.1G   67% /
tmpfs             99M     0   99M    0% /run/user/1001

$ df -i
ファイルシス   Iノード  I使用   I残り I使用% マウント位置
devtmpfs        123170    284  122886     1% /dev
tmpfs           125862      2  125860     1% /dev/shm
tmpfs           125862    367  125495     1% /run
tmpfs           125862     16  125846     1% /sys/fs/cgroup
/dev/xvda1     6290416 267819 6022597     5% /
tmpfs           125862      1  125861     1% /run/user/1001


参考

このエラーを解消するにあたってお世話になった記事たち。

まずは容量とはなんぞや?このエラーの言わんとしていることは?容量の調べ方は?の理解から始めた。

www.atmarkit.co.jp

easyramble.com

tackeyy.com

qiita.com

kisk0419.hatenablog.com

fatal: write error: No space left on device が出た場合は、不要ファイルを削除する - Qiita

saitodev.co

zenn.dev

www.wantanblog.com

itojisan.xyz

qiita.com

qiita.com

aws.amazon.com