
MariaDB 서비스가 예기치 않게 중지되는 MariaDB 데이터베이스 인스턴스(버전 10.2)와 관련된 특이한 문제가 발생했습니다. 나는 서버가 충돌하기 전에 MariaDB가 과도한 메모리를 소비하는지 확인하기 위해 cronjob을 사용하여 매분마다 상위 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를 실행할 때 웹 서버 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
Wilson Hauck 질문에 대한 답변:
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가지입니다.
첫 번째는 웹 서버와 데이터베이스(아마도 여기에도 일부 애플리케이션 계층이 있을 수 있음)의 구성을 살펴보고 사용 가능한 것보다 더 많은 RAM을 사용하려고 시도하지 않는지 확인하는 것입니다. 당신이 애플리케이션 서버나 웹 서버에 대해 우리에게 말하지 않았기 때문에 나는 실제로 조언할 수는 없습니다(그러나 여기에는프리포크 Apache에 대한 힌트, 선택적으로 PHP 사용). Mariadb에 관해서는 - 가서 사본을 얻으십시오mysqltuner.pl설치에 대해 실행하십시오.
이렇게 하면 대부분의 경우 메모리가 부족해지는 것을 방지할 수 있지만 커널이 제공하는 존재하지 않는 메모리의 양도 줄여야 합니다.
sysctl vm.overcommit_memory=2
sysctl vm.overcommit_ratio=20
...아직 OOM 킬러가 표시된다면 비율을 더 낮은 값으로 시도해 보세요.