☰

MariaDB 隨機崩潰

tag-icon • tag-icon linux mysql amazon-ec2 mariadb crash
MariaDB 隨機崩潰

我遇到了與我的 MariaDB 資料庫實例（版本 10.2）相關的特殊問題，導致我的 MariaDB 服務意外停止。我嘗試透過使用 cronjob 定期記錄每分鐘前 3 個進程的 RAM 使用情況來調查該問題，旨在確定 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 時，經常看到 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).

然而，網路伺服器從未出現過崩潰或運行中斷的情況。這個問題僅影響 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 那麼這不是解決您的問題的方法。

您需要做兩件事。

首先是查看您的網頁伺服器和資料庫的配置（可能還有一些應用程式層），以確保它們不會嘗試使用比您可用的更多的 RAM。由於您沒有告訴我們有關應用程式伺服器或網頁伺服器的信息，我無法真正提供建議（但這裡是預分叉 Apache 的提示，可選擇性地使用 PHP）。至於 Mariadb - 去拿一份副本mysqltuner.pl並針對您的安裝運行它。

這應該可以防止您在大多數情況下耗盡內存，但您還應該減少內核將分配的不存在的內存量：

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

....如果您仍然看到 OOM 殺手，請嘗試較低的比率值。

相關內容