EC2 t2.micro 實例中 CentOS8 上的 mariadb oom-killer

我在執行 nginx、mariadb、php 和 WordPress 的 t2.micro 實例 (1GB) 中似乎存在記憶體問題。

我可以看到 mariadb.service 經常被殺死（我使用了grep -e kill /var/log/messages下面的範例輸出）。如您所見，mysqld 正在殺死 mariadb（這不是自殺嗎？）。

我已經嘗試對 mariadb 進行各種調整和調整，但我認為這更像是一個整體系統問題。

當“崩潰”發生時，我無法隔離。我可以愉快地登錄到 WordPress 管理員，離開工作，當我切換到新區域（提示 dbase 呼叫）時，站點掛起。SSH 連接也會同時掛起。

t2.micro 是不是不夠強大？

Apr  9 11:22:32 ip-172-31-20-68 systemd[1]: mariadb.service: Main process exited, code=killed, status=9/KILL
Apr  9 11:23:25 ip-172-31-20-68 kernel: mysqld invoked oom-killer: gfp_mask=0x6200ca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0
Apr  9 11:23:25 ip-172-31-20-68 kernel: oom_kill_process.cold.28+0xb/0x10
Apr  9 11:23:25 ip-172-31-20-68 kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/system.slice/mariadb.service,task=mysqld,pid=6383,uid=27
Apr  9 11:23:25 ip-172-31-20-68 systemd[1]: mariadb.service: Main process exited, code=killed, status=9/KILL
Apr  9 11:27:04 ip-172-31-20-68 kernel: tuned invoked oom-killer: gfp_mask=0x6200ca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0
Apr  9 11:27:04 ip-172-31-20-68 kernel: oom_kill_process.cold.28+0xb/0x10
Apr  9 11:27:04 ip-172-31-20-68 kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/system.slice/mariadb.service,task=mysqld,pid=6483,uid=27
Apr  9 11:27:51 ip-172-31-20-68 NetworkManager[928]: <info>  [1617967671.1410] manager: rfkill: Wi-Fi enabled by radio killswitch; enabled by state file
Apr  9 11:27:51 ip-172-31-20-68 NetworkManager[928]: <info>  [1617967671.1411] manager: rfkill: WWAN enabled by radio killswitch; enabled by state file
Apr  9 12:04:48 ip-172-31-20-68 kernel: mysqld invoked oom-killer: gfp_mask=0x6200ca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0
Apr  9 12:04:48 ip-172-31-20-68 kernel: oom_kill_process.cold.28+0xb/0x10
Apr  9 12:04:48 ip-172-31-20-68 kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/system.slice/mariadb.service,task=mysqld,pid=1746,uid=27
Apr  9 12:04:48 ip-172-31-20-68 systemd[1]: mariadb.service: Main process exited, code=killed, status=9/KILL
Apr  9 12:06:04 ip-172-31-20-68 kernel: tuned invoked oom-killer: gfp_mask=0x6200ca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0
Apr  9 12:06:04 ip-172-31-20-68 kernel: oom_kill_process.cold.28+0xb/0x10
Apr  9 12:06:04 ip-172-31-20-68 kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/user.slice/user-1000.slice/session-3.scope,task=dnf,pid=1982,uid=0
Apr  9 12:08:30 ip-172-31-20-68 kernel: php-fpm invoked oom-killer: gfp_mask=0x6200ca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0
Apr  9 12:08:31 ip-172-31-20-68 kernel: oom_kill_process.cold.28+0xb/0x10
Apr  9 12:08:31 ip-172-31-20-68 kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/system.slice/mariadb.service,task=mysqld,pid=2126,uid=27
Apr  9 12:08:31 ip-172-31-20-68 systemd[1]: mariadb.service: Main process exited, code=killed, status=9/KILL

OOM 殺手是一個核心函式，它代表目前分配記憶體的程序進行操作。這可以是選擇被殺死以釋放記憶體的同一程序。

選擇規則通常選擇具有最大匿名記憶體（即折扣記憶體映射文件）到物理頁面（即折扣被換出或從未被寫入的記憶體）映射的程序。

通常可以以犧牲性能為代價來調整數據庫以使用更少的記憶體，並且我還希望預設調整假設數據庫伺服器是專用機器並且應該將其所有資源都用於這個單一任務，即不是你在這裡做什麼。

所以這裡有多種途徑：

1. 執行專用於數據庫的單獨 VM
2. 調整數據庫設置以使用更少的記憶體
3. 使用更大的虛擬機

數據庫通常擅長適應可用的記憶體量，並將其用於查詢優化器已知的記憶體，並且可以作為成本計算的一部分（與作業系統級別的磁碟記憶體相反，後者是不可預測的），因此要麼限制到某個值，為其他軟體留下足夠的空間，或者確保沒有其他軟體需要空間，很好地解決了這個問題。

如果這仍然不夠，您將需要更大的虛擬機。

添加交換空間沒有幫助，因為它使數據庫內部記憶體的訪問時間不可預測，因此數據庫將開始創建次優查詢計劃，因為它假定數據已記憶體並且對記憶體中副本的訪問將比重新載入更快來自磁碟的數據——但是在你為 I/O 付費的虛擬機上交換空間不是一個好主意。

引用自：https://serverfault.com/questions/1059879