残容量のメモ、ログサイズ確認のメモ、Cloud9が重くなってきた時は容量不足の可能性がある為サイズ確認

$ 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からログアウト、ログインしたら、動作が遅いのが直った。

 結局、原因は何だったんだろう。