Я столкнулся со своеобразной проблемой, связанной с моим экземпляром базы данных MariaDB (версия 10.2), из-за которой моя служба MariaDB неожиданно останавливается. Я попытался исследовать проблему, регулярно регистрируя использование оперативной памяти тремя основными процессами каждую минуту с помощью cronjob, чтобы определить, потребляет ли MariaDB избыточную память до сбоя сервера. Однако после проведения этого расследования я склонен полагать, что чрезмерное использование оперативной памяти не является основной причиной проблемы.
Кроме того, всякий раз, когда сервер давал сбой, я пытался просмотреть журналы 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, я чаще вижу, что веб-сервер 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).
Однако веб-сервер никогда не сталкивался с сбоями или перебоями в работе. Проблема касается только сервиса 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
Ответы на вопросы Уилсона Хаука:
Относительно оперативной памяти:
[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, то это НЕ способ исправить вашу проблему.
Вам нужно сделать две вещи.
Первое — это посмотреть на конфигурацию вашего веб-сервера и базы данных (и, вероятно, здесь также есть какой-то уровень приложений), чтобы убедиться, что они не пытаются использовать больше оперативной памяти, чем у вас есть. Поскольку вы не рассказали нам о сервере приложений или веб-сервере, я не могу ничего посоветовать (но вотподсказка для Apache pre-fork, опционально с PHP). Что касается Mariadb - скачайте копиюmysqltuner.plи запустите его на своей установке.
Это должно предотвратить нехватку памяти в большинстве случаев, но вам также следует уменьшить объем несуществующей памяти, которую будет выдавать ядро:
sysctl vm.overcommit_memory=2
sysctl vm.overcommit_ratio=20
...и попробуйте уменьшить значения коэффициента, если вы все еще видите OOM killer.