見出し画像

EBSのディスクが溢れて困ったンゴな話

まあこういうのは減らすか増やすしかねえけど、増やしとくかあ。現状

admin@ip-172-31-31-170:/backup % df -h
ファイルシス    サイズ  使用  残り 使用% マウント位置
udev              895M     0  895M    0% /dev
tmpfs             187M  660K  187M    1% /run
/dev/nvme0n1p1     20G   18G  1.3G   94% /
tmpfs             935M     0  935M    0% /dev/shm
tmpfs             5.0M     0  5.0M    0% /run/lock
/dev/nvme1n1p1     30G   27G  898M   97% /backup
/dev/nvme0n1p15   127M  148K  127M    1% /boot/efi
tmpfs             187M     0  187M    0% /run/user/1000


30から50に増量する

でまあディスクはでかくなってもファイルシステムはでかくなりませんよ、みたいな事になるわけだよね。この辺は昔から物理ディスクを触ってきた人間には手慣れた話かもしれないが…

# cfdisk /dev/nvme1n1
GPT PMBR size mismatch (62914559 != 104857599) will be corrected by write.
The backup GPT table is not on the end of the device. This problem will be corrected by write.
                               Disk: /dev/nvme1n1
               Size: 50 GiB, 53687091200 bytes, 104857600 sectors
          Label: gpt, identifier: 6B403226-E710-B64B-9A98-2D303FEA9628

    Device               Start         End     Sectors   Size Type
>>  /dev/nvme1n1p1        2048   104857533   104855486    50G Linux filesystem







 ┌────────────────────────────────────────────────────────────────────────────┐
 │ Partition UUID: 76B7E2AA-793B-6F4A-B994-0C1247767739                       │
 │ Partition type: Linux filesystem (0FC63DAF-8483-4772-8E79-3D69D8477DE4)    │
 │Filesystem UUID: 0f268c61-d355-4dac-b93a-4940565b4f61                       │
 │     Filesystem: ext4                                                       │
 │     Mountpoint: /backup (mounted)                                          │
 └────────────────────────────────────────────────────────────────────────────┘
     [ Delete ]  [ Resize ]  [  Quit  ]  [  Type  ]  [  Help  ]  [  Write ]
     [  Dump  ]
                              Partition 1 resized.

resizeしてwrite

その後でresize2fsを仕掛けるが、特殊なfsを使ってる人は注意

Filesystem at /dev/nvme1n1p1 is mounted on /backup; on-line resizing required
old_desc_blocks = 4, new_desc_blocks = 7
The filesystem on /dev/nvme1n1p1 is now 13106935 (4k) blocks long.
# df -h /backup/
ファイルシス   サイズ  使用  残り 使用% マウント位置
/dev/nvme1n1p1    50G   27G   20G   58% /backup

増えましたね。終わり。

ところでIOPSとかについてちゃんと考えたことあるか?

Input/Output Operations Per Second

ということ

ここでは

150/3000
1 GiB あたり 3 IOPS のベースライン、最小 100 IOPS、3000 IOPS にバースト可能。

と書いてある。ちなみにtune2fsとかで調べてみてもいいけど何も考えずにfsを作るとたいてい4kbブロックになっているはずだ。

1GBのファイルをこの条件で転送するときに何秒かかるかというのは大体計算できるのでchatgptにやらせる


このようにバーストできるか、できないかでかかる時間が全然変わってきちゃうんだよね。なお、このバーストできるかできないかは残ってるクレジットに依存する。クレジットなんて見たこともねえわって人は見といてもいいかも。なお


このボリュームタイムだとサイズに応じてIOPSやクレジットも変化するのでまあ基本的に「デカい方が速い」と考えていい(gp2は)。

それ以外のタイプ

gp3

gp3はセッティングがさらに細かい。ここでもChatGPTに解説してもらおう。


マグネティック

一番安価であるがIOPSの設定がない。速度は使ってみないとわからんということだけどまあ大抵遅いってことになるはずだ。基本的にはもうこれは選択しないと思う

io1


既にエラーになっているが30Gで1500IOPS(最大)を常に保証しつづける。

io2

まあ基本的にここまでものものは用無しだと思う

30Gの価格

https://aws.amazon.com/jp/ebs/pricing/

1USD=150JPY

gp2はクレジット制でベースラインがちょっと高い。gp3は安いんだけど設定によってはちょっと高くなることもあるよ、って感じ。何も考えたくないならgp2にするべきだけどクレジットの数はモニタリングしといた方がいいかもしれないね(大事なサービスなら)

この記事が気に入ったらサポートをしてみませんか?