OCIの無料インスタンス VM.Standard.A1.Flex (Always Free)
を一生こすり続けている皆さんこんにちは。50GBのBootボリュームが一瞬でなくなってしまったりしてお困りではありませんか? 個人的にストレージ確保に非常に苦労しているので、この記事ではその知見をまとめます。
対象環境
Key | Value |
---|---|
OS | Ubuntu 20.04.6 LTS (GNU/Linux 5.15.0-1048-oracle aarch64) |
インスタンス | VM.Standard.A1.Flex |
Bootボリューム | 50GB (99%消費) |
Blockボリューム | 150GB (100%消費 保管用のため消せない) |
備考 | DockerとPortainerを使用 |
消せるものの調査方法
まず現状99%消費しているので、一体何が原因なのかを調べます。
ストレージ使用量の確認
-
sudo du -hs * | sort -hr
- カレントディレクトリにあるフォルダそれぞれのサイズを表示します
-
sudo ncdu -x -q
- カレントディレクトリ配下のフォルダそれぞれのサイズをグラフィカルにCUI表示します
- 要
sudo apt install ncdu
- duコマンドを使うよりとても簡単に確認できます
- (実行時のユーザーがアクセス権限を持つフォルダのサイズしか計算されません
- 要
- カレントディレクトリ配下のフォルダそれぞれのサイズをグラフィカルにCUI表示します
-
sudo docker system df -v
- Docker関連データ(コンテナ/イメージ/ボリューム)のサイズを一括表示します
-
journalctl --disk-usage
- Journal(systemdで動くサービス系のログ)保存量を表示します
インスタンス情報の確認
-
uname -r
- 現在のカーネルバージョンを確認します
-
cat /etc/os-release
- 現在のOSバージョンを確認します
-
df -h --total
- ファイルシステム毎(ボリューム毎)の使用率を表示します
消せるもの一覧
大体どのフォルダが容量を取っているのかわかったので消せそうなものを調べました。
使っていないDocker関連データ
一般データ削除
- 不要なイメージ削除
-
docker image prune -a
- コンテナから参照されていない未使用イメージとdangling image(タグを持っていないかつ参照されないイメージ)を削除します
-
- 不要なネットワーク削除
-
docker network prune
- コンテナからも参照されていないネットワークを削除します
-
- 不要なボリューム削除
-
docker volume prune
- コンテナからも参照されていないボリュームを削除します
-
- 不要なコンテナ削除
-
docker container prune
- "停止中のコンテナ"を削除します
-
- 参考
- https://docs.docker.jp/config/pruning.html
- Portainerを利用している場合 ログ以外はWebUIからポチポチで削除できます
ログデータの削除
ncduで歩き回ると /var/lib/docker/containersにやけにでかいファイルがありました。ログをコンテナ内で吐いている場合、デフォルトだとここにログが出力され、しかもサイズ制限がないため、すごく巨大化します。
- 削除方法
-
cat /dev/null > /var/lib/docker/containers/(ハッシュ)/(ハッシュ)-json.log
- ログをnullで上書きする
-
- 参考
journalctl(var/logフォルダ)の不要なログ
OSデーモンやnginxのアクセスログなどが場合によっては貯まる可能性があります。
- 削除方法
-
sudo journalctl --vacuum-size=1024M
- (大雑把に削除で問題ない場合) 1024MB残して残りを消します
-
- 参考
適用済みのカーネルアップデートファイル
Oracleは、非情に親切なことに最新カーネルを勝手にダウンロードしてきます。通常、再起動したら最新版が反映され、古いものが削除されるのですが、なぜか残っていることがあります。この場合1カーネルバージョンに付き494MBと結構な量を消費してしまいます。
-
削除方法
-
uname -r
で 現在のカーネルバージョン確認 sudo rm /usr/lib/modules/(現在のカーネルバージョンより古いもの)-oracle
- ※今利用しているカーネルを消さないようにバージョンは十分確認してください
- ※安全な削除方法ではない可能性があります
- (aptから安全に削除できるという話もあったように思うのですが詳細を失念しました...
-
-
参考
最大ファイルサイズを制限する対策
削除して容量を確保した後は、そもそも削除操作をしなくても済むようにする方法を取っておきましょう。
var/logのログファイルサイズ制限
全体的なjournalログサイズの最大保存量を制限することができます。
- 手順
sudo nano /etc/systemd/journald.conf
-
SystemMaxFileSize=1024M
と記載して保存 -
sudo systemctl restart systemd-journald
で再起動して反映
- 参考
Dockerのログファイルサイズ制限
dockerdの設定を行い、最大ログサイズを制限することができます。
- 手順
-
sudo nano /etc/docker/daemon.json
(daemon.jsonを作った覚えがない場合は新規ファイル) - 下記のような内容を貼り付けて保存し
sudo systemctl restart docker
を実行
-
{
"log-driver": "json-file",
"log-opts": {
"max-size": "1024m",
"max-file": "10"
}
}
- 参考
(MySQLを動かしている場合) DELETEクエリの調査
DELETEで行を削除してもストレージは開放されません。 実装が悪い場合、ゴミデータが溜まり大変なことになります。
- 対応方法
- DB内から見たファイルサイズと、実体のファイルサイズを確認する
- 大きく異なる場合は mysqldumpして作り直したり、実装の改善を検討する
- DB内から見たファイルサイズと、実体のファイルサイズを確認する
- 参考
- MySQLのDBから見たサイズを確認する方法
- Dockerから見たボリュームサイズを確認する方法
- 失敗談