$ df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 483M 60K 483M 1% /dev
tmpfs 493M 0 493M 0% /dev/shm
/dev/xvda1 7.9G 1.6G 6.2G 21% /
$ df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 472M 68K 472M 1% /dev
tmpfs 482M 0 482M 0% /dev/shm
/dev/nvme0n1p1 7.9G 1.6G 6.2G 20% /
duとdfコマンドの容量単位
【Linux】duとdfコマンドの容量単位 | ミーミルの泥泉
-b キロバイト単位。duのみ
-k キロバイト単位
-m メガバイト単位
-h 人間が読みやすい単位。ギガバイトであればG、メガバイトであればM、キロバイトであればK
$ ls -lSha /var/log/
$ sudo ls -lSha /var/log/httpd/
ログが肥大化していないか
/var/log/httpd , /var/log/cron , messages , cloud-init.log , httpd/error_log
Cloud9のターミナルが重くなってきたので、ストレージの重い場所を検索。
たぶん機能の redis の composerインストールが影響してそう。
検索する階層を指定
sudo du -h --max-depth=1 /usr/
3.2G /usr
3.8G /var
2.2G /home
こいつが大きくなってた
/var/lib/docker/overlay2
dockerで/var/lib/docker/overlay2 が肥大化した時の対処 - Tech Tips
docker system df
docker system prune --all
これで使用率100%が0%になって、/var のサイズが3.8Gから1.5Gになった
ターミナルのレスポンスがとても速くなった。
ちなみに削除作業の途中で、/var/lib/docker/overlay2 を /var/lib/docker/overlay_delete_2 にリネームしたら、またoverlay2が作成された。
その後AMIを取って、overlay_delete_2 を削除した。
しかし、しばらくすると、また遅くなってきた。
この前、入れたredisが原因かと思い、redisを止めてみたが、改善せず。
sudo e4defrag -c /
sudo e4defrag /
デフラグを実行してみた。
Linux Mint - Ext4 ファイルシステムをデフラグ! - mk-mode BLOG
改善せず。。
CPU
$ top
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3145 root 20 0 419m 50m 30m S 0.3 2.5 0:07.40 containerd
1 root 20 0 19696 2456 2200 S 0.0 0.1 0:01.27 init
メモリ
$ free
total used free shared buffers cached
Mem: 2041316 1936440 104876 1864 461816 631228
-/+ buffers/cache: 843396 1197920
Swap: 499996 512 499484
freeコマンド | Linux技術者認定 LinuC | LPI-Japan
ストレージ
$ df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 987M 60K 987M 1% /dev
tmpfs 997M 0 997M 0% /dev/shm
/dev/xvda1 16G 8.2G 7.4G 53% /
いずれも余裕あり。
しばらく時間が経って、AWSからログアウト、ログインしたら、動作が遅いのが直った。
結局、原因は何だったんだろう。