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

Question

我在运行 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

Answer 1

OOM 终止程序是代表当前分配内存的进程运行的内核函数。该进程可能与被选择终止以释放内存的进程相同。

选择规则通常选择匿名内存（即不考虑内存映射文件）到物理页面（即不考虑已换出或从未写入的内存）映射最大的进程。

通常可以调整数据库以使用更少的内存但牺牲性能，并且我还希望默认调整假设数据库服务器是一台专用机器并且应该将其所有资源投入到这个单一任务中，但这不是您在这里所做的。

因此，这里有多种途径：

1. 运行专用于数据库的单独虚拟机
2. 调整数据库设置以使用更少的内存
3. 使用更大的虚拟机

数据库通常能够很好地适应可用的内存量，并将其用于查询优化器已知的缓存，并可以作为成本计算的一部分（而不是不可预测的操作系统级磁盘缓存），因此要么将其限制为某个值，为其他软件留出足够的空间，要么确保没有其他软件需要空间，这样就可以很好地解决这个问题。

如果这仍然不够，您将需要更大的虚拟机。

添加交换空间没有帮助，因为它使得数据库内部缓存的访问时间变得不可预测，因此数据库将开始创建次优查询计划，因为它假定数据已被缓存，并且访问内存中的副本将比从磁盘重新加载数据更快 - 但无论如何，在您为 I/O 付费的虚拟机上交换空间并不是一个好主意。