![MariaDB 随机崩溃](https://linux22.com/image/789488/MariaDB%20%E9%9A%8F%E6%9C%BA%E5%B4%A9%E6%BA%83.png)
我遇到了一个与 MariaDB 数据库实例(版本 10.2)相关的特殊问题,导致我的 MariaDB 服务意外停止。我尝试通过使用 cronjob 定期记录每分钟前 3 个进程的 RAM 使用情况来调查该问题,目的是确定 MariaDB 是否在服务器崩溃前消耗了过多的内存。然而,在进行这项调查后,我倾向于相信过多的 RAM 使用并不是问题的根本原因。
此外,每当服务器崩溃时,我都会尝试使用以下命令查看 MariaDB 日志:
sudo cat /var/log/mariadb/mariadb.log
- 此命令未返回任何结果。sudo systemctl status mariadb -l
- 此命令产生以下输出:
另外,这里是操作系统信息的屏幕截图:
[someuser ~]$ uname -a
Linux ec2.internal .amzn2.x86_64 #1 SMP Thu Dec 8 01:29:11 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
[someuser ~]$ hostnamectl
Static hostname: <ip>.ec2.internal
Icon name: computer-vm
Chassis: vm
Machine ID: -
Boot ID: -
Virtualization: xen
Operating System: Amazon Linux 2
CPE OS Name: cpe:2.3:o:amazon:amazon_linux:2
Kernel: Linux <ip>.amzn2.x86_64
Architecture: x86-64
非常感谢您帮助诊断和解决此服务器稳定性问题。任何有关如何进行的见解和指导都将非常宝贵。
对@NikitaKipriyanov 评论的回答:嗨@NikitaKipriyanov,谢谢你的提问。按照你的建议,我运行dmesg -T | grep mysql
并发现了这一点(仅粘贴相关数据):
[Mon Sep 18 17:37:34 2023] [ 26231] 27 26231 29965 52 61440 0 0 mysql-prepare-d
[Tue Sep 19 14:04:29 2023] [ 26839] 27 26839 367222 19121 630784 0 0 mysqld
[Tue Sep 19 14:04:31 2023] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/,task=mysqld,pid=26839,uid=27
[Tue Sep 19 14:04:31 2023] Out of memory: Killed process 26839 (mysqld) total-vm:1468888kB, anon-rss:76484kB, file-rss:0kB, shmem-rss:0kB, UID:27 pgtables:616kB oom_score_adj:0
[Tue Sep 19 14:05:41 2023] [ 29800] 27 29800 2326 26 61440 0 0 mysql-check-soc
[Tue Sep 19 14:05:52 2023] [ 29800] 27 29800 2326 26 61440 0 0 mysql-check-soc
我们可以看到日期和时间与服务停止工作的时间大致相符。我想说的是,当我运行 dmesg -TI 时,经常会看到 Web 服务器 httpd 崩溃:
[Tue Sep 19 14:13:00 2023] [ 30195] 0 30195 143596 2011 839680 0 0 httpd
[Tue Sep 19 14:13:00 2023] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/,task=httpd,pid=28937,uid=48
[Tue Sep 19 14:13:00 2023] Out of memory: Killed process 28937 (httpd) total-vm:628120kB, anon-rss:11732kB, file-rss:0kB, shmem-rss:96kB, UID:48 pgtables:860kB oom_score_adj:0
[Tue Sep 19 14:13:17 2023] systemd-journald[30073]: Received SIGTERM from PID 1 (systemd).
但是,Web 服务器从未出现过崩溃或运行中断的情况。该问题仅影响 MariaDB 服务。该问题偶尔才会出现在 MariDB 服务上,例如每 3 到 5 天出现一次。这些是我在 /var/log/mariadb 文件夹中仅有的日志:
[root@ip mariadb]# ls -la
total 28
drwxr-x--- 2 mysql mysql 146 Sep 20 03:48 .
drwxr-xr-x 10 root root 4096 Sep 26 03:23 ..
-rw------- 1 mysql mysql 0 Sep 20 03:48 mariadb.log
-rw------- 1 mysql mysql 8714 Sep 7 12:40 mariadb.log-20230908
-rw------- 1 mysql mysql 2005 Sep 15 18:02 mariadb.log-20230916.gz
-rw------- 1 mysql mysql 1917 Sep 18 17:39 mariadb.log-20230919.gz
-rw------- 1 mysql mysql 1909 Sep 19 14:16 mariadb.log-20230920.gz
[root@ip mariadb]# pwd
/var/log/mariadb
这也是的输出sysctl -A | grep panic
:
[root@ip log]# sysctl -A | grep panic
fs.xfs.panic_mask = 0
kernel.hardlockup_panic = 0
kernel.hung_task_panic = 0
kernel.panic = 30
kernel.panic_on_io_nmi = 0
kernel.panic_on_oops = 0
kernel.panic_on_rcu_stall = 0
kernel.panic_on_unrecovered_nmi = 0
kernel.panic_on_warn = 0
kernel.panic_print = 0
kernel.softlockup_panic = 0
kernel.unknown_nmi_panic = 0
sysctl: reading key "net.ipv6.conf.all.stable_secret"
sysctl: reading key "net.ipv6.conf.default.stable_secret"
sysctl: reading key "net.ipv6.conf.eth0.stable_secret"
sysctl: reading key "net.ipv6.conf.lo.stable_secret"
vm.panic_on_oom = 0
Wilson Hauck 问题的答案:
关于RAM:
[ec2-user@ip ~]$ free -h
total used free shared buff/cache available
Mem: 964M 333M 197M 724K 433M 451M
Swap: 0B 0B 0B
SELECT COUNT(*) FROM information_schema.tables;
- 238
SHOW GLOBAL STATUS;
- 返回的行数太多,无法粘贴到这里,您要查找哪个值
SHOW GLOBAL VARIABLES;
- 相同的
我应该如何发送所有请求的查询的输出?
答案1
我猜对了能获得奖品吗?
这里和互联网上其他地方有很多关于如何解决这个问题的答案。不幸的是,很多答案都是错的。如果他们提到 oom_adj 或 oom_score_adj,那么这不是解决你的问题的方法。
您需要做两件事。
首先是查看您的 Web 服务器和数据库的配置(这里可能还有一些应用程序层),以确保它们不会占用比您可用的更多的 RAM。由于您没有告诉我们有关应用程序服务器和 Web 服务器的信息,因此我无法提供建议(但这里有Apache 预分叉提示,可选使用 PHP)。至于 Mariadb - 去获取一份mysqltuner.pl并根据您的安装运行它。
这应该可以防止您在大多数情况下耗尽内存,但您还应该减少内核分配的不存在的内存量:
sysctl vm.overcommit_memory=2
sysctl vm.overcommit_ratio=20
...如果您仍然看到 OOM killer,请尝试降低该比率的值。