☰

MariaDBがランダムにクラッシュする

tag-icon • tag-icon linux mysql amazon-ec2 mariadb crash
MariaDBがランダムにクラッシュする

MariaDB データベース インスタンス (バージョン 10.2) に関連する奇妙な問題が発生し、MariaDB サービスが予期せず停止しました。サーバーがクラッシュする前に MariaDB が過剰なメモリを消費しているかどうかを確認するために、cronjob を使用して 1 分ごとに上位 3 つのプロセスの RAM 使用量を定期的に記録することで、この問題を調査しようとしました。しかし、この調査を行った結果、過剰な RAM 使用量が問題の根本原因ではないと考えるようになりました。

さらに、サーバーがクラッシュするたびに、次のコマンドを使用して MariaDB ログを確認しようとしました。

  • sudo cat /var/log/mariadb/mariadb.log- このコマンドは結果を返しません。
  • sudo systemctl status mariadb -l- このコマンドにより、次の出力が生成されます。

コマンドの結果

また、OS 情報のスクリーンショットは次のとおりです。

[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 サービスにのみ影響します。この問題は、たとえば 3 ～ 5 日ごとに MariDB サービスにのみ時々発生します。これらは、/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

ウィルソン・ハウクの質問への回答:

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 について言及されている場合、これは問題を解決する方法ではありません。

やるべきことは2つあります。

まず、Webサーバーとデータベース（おそらくアプリケーション層もここにあります）の設定を確認して、使用可能なRAMよりも多くのRAMを消費しないようにします。アプリケーションサーバーとWebサーバーについては何も説明されていないので、私は実際にアドバイスすることはできません（ただし、ここにあります）。Apacheのプリフォークのヒント（PHPもオプションで使用できます）。Mariadbについては、翻訳元インストールに対して実行します。

これにより、ほとんどの場合、メモリ不足は防げるはずですが、カーネルが配布する存在しないメモリの量も減らす必要があります。

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

...それでも OOM キラーが発生する場合は、比率の値を下げてみてください。

関連情報