MariaDB случайным образом теряет устойчивость.

Я столкнулся с необычной проблемой, связанной с моей инстанцией базы данных MariaDB (версия 10.2), которая вызывает неожиданное прекращение работы службы MariaDB. Я пытался исследовать проблему, регулярно записывая использование ОЗУ топ-3 процессов каждую минуту с помощью 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 -T, я чаще вижу, что веб-сервер 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. Проблема появляется время от времени только в службе MariaDB, например, каждые 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:

Относительно ОЗУ:

[ec2-user@ip ~]$ free -h
              всего       использовано     свободно    общая    буферы/кэш   доступно
Mem:           964M        333M        197M        724К        433M        451M
Swap:            0B          0B          0B

SELECT COUNT(*) FROM information_schema.tables; – 238

SHOW GLOBAL STATUS; – Возвращает слишком много строк, чтобы их вставлять сюда, какое значение вас интересует

SHOW GLOBAL VARIABLES;– То же самое

Как я должен отправить вывод всех запрошенных запросов?

Я получу приз за правильно угаданное?

Здесь и в других местах в интернете есть множество ответов о том, как это исправить. К сожалению, многие из них ошибочны. Если они упоминают oom_adj или oom_score_adj, то это НЕ способ исправить вашу проблему.

Есть 2 вещи, которые вам нужно сделать.

Во-первых, нужно взглянуть на вашу конфигурацию веб-сервера и базы данных (и, вероятно, здесь также есть уровень приложения) и убедиться, что они не пытаются использовать больше оперативной памяти, чем у вас доступно. Поскольку вы не рассказали нам об сервере приложений или веб-сервере, я не могу точно посоветовать (но вот подсказка для пред-форк Apache, возможно, с PHP). Что касается Mariadb – возьмите копию mysqltuner.pl и запустите против вашего установки.

Это должно предотвратить нехватку памяти в большинстве случаев, но вам также следует уменьшить количество несуществующей памяти, которую ядро будет выдавать:

sysctl vm.overcommit_memory=2
sysctl vm.overcommit_ratio=20

…и пытаться снизить значения для соотношения, если вы все еще видите «убийцу» OOM.

sysctl vm.overcommit_memory=2

sysctl vm.overcommit_ratio=20

опасно, так как получаются ошибки “нельзя выделить память” при каждой bash-команде, и ничего не будет работать, включая postfix и apache, пока я не перезагрузил мой экземпляр Linux EC2 в консоли aws.amazon.com, и изначальные безопасные значения 0 и 50 не были восстановлены соответственно, чтобы я мог подключиться по ssh, и все службы были перезапущены нормально.

Если mysqld падает с ошибкой «убийца» OOM, просто перезапустите его – все по-старому:

service mysqld start

Не меддайте с значениями vm.overcommit_memory или vm.overcommit_ratio, иначе рискуете потерять все на сервере, если он не будет резервным.