Ich habe ein eigenartiges Problem im Zusammenhang mit meiner MariaDB-Datenbankinstanz (Version 10.2) festgestellt, das dazu führt, dass mein MariaDB-Dienst unerwartet beendet wird. Ich habe versucht, das Problem zu untersuchen, indem ich mithilfe eines Cronjobs regelmäßig die RAM-Nutzung der drei wichtigsten Prozesse pro Minute protokolliert habe, um festzustellen, ob MariaDB übermäßig viel Speicher verbraucht, bevor der Server abstürzt. Nach dieser Untersuchung bin ich jedoch geneigt zu glauben, dass übermäßige RAM-Nutzung nicht die Grundursache des Problems ist.
Darüber hinaus habe ich bei jedem Serverabsturz versucht, die MariaDB-Protokolle mit den folgenden Befehlen zu überprüfen:
sudo cat /var/log/mariadb/mariadb.log– Dieser Befehl gibt keine Ergebnisse zurück.sudo systemctl status mariadb -l- Dieser Befehl erzeugt folgende Ausgabe:
Hier ist außerdem ein Screenshot der Betriebssysteminformationen:
[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
Ich wäre Ihnen für Ihre Hilfe bei der Diagnose und Lösung dieses Serverstabilitätsproblems sehr dankbar. Alle Erkenntnisse und Hinweise zum weiteren Vorgehen wären von unschätzbarem Wert.
Antworten auf den Kommentar von @NikitaKipriyanov: Hallo @NikitaKipriyanov, danke für die Fragen. Ich bin deinem Rat gefolgt dmesg -T | grep mysqlund habe Folgendes herausgefunden (ich habe nur die relevanten Daten eingefügt):
[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
Wie wir sehen, stimmen Datum und Uhrzeit des Absturzes des Dienstes ziemlich gut überein. Ich möchte noch erwähnen, dass ich beim Ausführen von dmesg -TI häufiger sehe, dass der Webserver httpd abgestürzt ist:
[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).
Allerdings kam es beim Webserver nie zu Abstürzen oder Betriebsunterbrechungen. Das Problem betrifft nur den MariaDB-Dienst. Das Problem tritt nur beim MariDB-Dienst gelegentlich auf, z. B. alle 3 bis 5 Tage. Dies sind die einzigen Protokolle, die ich nur im Ordner /var/log/mariadb habe:
[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
Hier ist auch die Ausgabe von 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
Antworten auf Wilson Haucks Fragen:
Zum Thema 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;- Gibt zu viele Zeilen zurück, um sie hier einzufügen. Nach welchem Wert suchen Sie?
SHOW GLOBAL VARIABLES;- Dasselbe
Wie soll ich die Ausgabe aller angeforderten Abfragen senden?
Antwort1
Bekomme ich für meine richtige Vermutung eine Belohnung?
Hier und anderswo im Internet gibt es viele Antworten, wie man dieses Problem beheben kann. Leider sind viele davon falsch. Wenn dort oom_adj oder oom_score_adj erwähnt werden, ist dies NICHT die Lösung für Ihr Problem.
Es gibt zwei Dinge, die Sie tun müssen.
Als Erstes sollten Sie sich die Konfiguration Ihres Webservers und der Datenbank ansehen (und vermutlich auch die Anwendungsebene), um sicherzustellen, dass diese nicht versuchen, mehr RAM zu verbrauchen, als Ihnen zur Verfügung steht. Da Sie uns weder etwas über den Anwendungsserver noch über den Webserver erzählt haben, kann ich Ihnen nicht wirklich weiterhelfen (aber hier istein Hinweis für Pre-Fork Apache, optional mit PHP). Was Mariadb betrifft - holen Sie sich eine Kopie vonmysqltuner.plund führen Sie es für Ihre Installation aus.
Dadurch sollte verhindert werden, dass Ihnen die meiste Zeit der Arbeitsspeicher ausgeht. Gleichzeitig sollten Sie aber auch die Menge an nicht vorhandenem Arbeitsspeicher reduzieren, die der Kernel ausgibt:
sysctl vm.overcommit_memory=2
sysctl vm.overcommit_ratio=20
... und versuchen Sie niedrigere Werte für das Verhältnis, wenn Sie immer noch den OOM-Killer sehen.