雖然這是一個常規動作，但是我最近發現一個特別的配置。
OOM 不是經常發生的事情，他是一個偶發事件，通常是因為業務流量突增，或是Java memory leak，之所以要說Java 因為他最容易出問題，code 寫得好就是Enterprise level，code 寫得差就是 OOM level。
一般來說我會將swap 空間放置於ebs 上，這樣做沒什麼問題，但極端情況下很可能會導致整個ec2 失去響應，那麼這時候你可以使用第二塊較小的單獨的data volume 來做swap，或者直接啟動具有instance store 的ec2，使用instance store 的高速ssd 來swap。
使用ebs 來swap：
fallocate -l 1G /home/swapfile
chmod 600 /home/swapfile
mkswap /home/swapfile
swapon /home/swapfile
Setting up swapspace version 1, size = 1024 MiB (1073737728 bytes)
no label, UUID=12438694-fc0d-4e8b-b7a8-41c6a9e38971添加到fstab:
/home/swapfile none swap sw 0 0使用instance store 來swap
mkswap /dev/nvme1n1
swapon /dev/nvme1n1
Setting up swapspace version 1, size = 54.9 GiB (58999992320 bytes)
no label, UUID=3afa04d4-787f-4c31-a491-3581a41c3bb1添加到fstab:
UUID=3afa04d4-787f-4c31-a491-3581a41c3bb1 none swap sw 0 0instance store 做swap 的效果非常好，因為本地的高速ssd 可以承載較高的iops 和throughput ，可以抗住數倍於memory size 的workload，當然，這還要看你的應用類型和可以接受的響應時間。
OK，這些方式都要花錢，那麼有沒有不花錢，又可以避免在短暫的異常下OOM 的辦法？畢竟一說到要花更多的錢，老闆都會很不開心。
今天要說的是zram，從名字就可以看出他就是zip ram的意思，在Amazon Linux 2023 中已經預裝了相關的組件，可以直接修改配置文件即可啟用這項功能。
我也是偶然發現他的，因為我發現在micro type 的instance 上才會有swap 而更大的instance type 沒有，而且在更換instance type 的時候他會自己更動。
在預設的配置文件中，只有memory 小於800M 的instance type 才會啟用一個和memory 大小相同的zram device，只需要將host-memory-limit 改為超過當前instance type memory size 的大小，重啟即可。
cat /usr/lib/systemd/zram-generator.conf
# This config file enables a /dev/zram0 device with the default settings:
# — size — same as available RAM or 8GB, whichever is less
# - host-memory-limit: Enable only on small instance types (less than 800MB)
# — compression — most likely lzo-rle
#
# To disable, uninstall zram-generator-defaults or create empty
# /etc/systemd/zram-generator.conf file.
# zram0 defaults to swap
[zram0]
# Up to 8GiB of zram, follows Fedora/CentOS defaults
zram-size = min(ram, 8192)
# Instances with more than 800MiB of RAM don't need this on AL2023
host-memory-limit=4096
# This is the kernel default, fastest but maybe we want zstd for
# small instances which compresses more ?
compression-algorithm=lzo-rle
看看加上沒有：
zramctl
NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 lzo-rle 3.7G 11.7M 336.5K 708K 1 [SWAP]壓縮比例可以到多少？
這是個玄學，我還沒有找到可信的評測，但是廣泛的評價是可以從 1:1 到 3:1，畢竟放入memory 的data 有些是已經壓縮過的，那麼就只能是團進團出，沒壓縮過的data 也許可以多一點點。
回到之前的問題，這主要是為了解決在短暫的異常下不要那麼容易OOM，他也可能帶來一些副作用，比如CPU負載上升，但和不要OOM 比起來似乎沒有那麼重要，持續的memory leak 仍會導致OOM發生，任何形式的swap 都只是應對偶然的突發狀況，而不是長期性的超過memory size 的使用，如果已經預期當前的application workload 會使用到超過instance type 的memory size，就應該要及時的升級。
