메모리 부족으로 인한 MySQL 다운 오류 없이 저사양 VPS에서 Debian 12를 실행하는 방법

메모리가 부족한 VPS에서도 데비안 12와 데이터베이스를 실행할 수 있지만, 안정성은 MySQL의 캐시 설정뿐만 아니라 전체 워크로드에 따라 달라집니다. 사용 가능한 메모리가 부족해지면 Linux는 메모리 부족(OOM) 킬러를 호출하여 시스템의 나머지 부분을 보호하기 위해 프로세스를 종료할 수 있습니다. 만약 해당 프로세스가 데이터베이스라면, 갑작스러운 시스템 충돌처럼 보일 수 있습니다. 실질적인 목표는 지속적인 메모리 압박을 방지하고 커널이 실제로 어떤 프로세스를 종료했는지 확인하는 것입니다. 어떤 튜닝 설정도 OOM 이벤트가 절대 발생하지 않도록 보장할 수는 없습니다.

데비안 12는 MySQL을 실행하고 있나요, 아니면 MariaDB를 실행하고 있나요?

서버 구성을 변경하기 전에 서버를 확인하십시오. Debian 12(Bookworm)는 기본 default-mysql-server패키지로 MariaDB를 사용하며, Oracle MySQL은 별도의 설치 경로가 있습니다. Debian의 패키지 정보에는 MariaDB가 해당 메타패키지의 서버 종속성으로 표시됩니다. 다음 명령을 실행하십시오.

mariadb --version
mysql --version
dpkg-query -W -f='${Package} ${Version}\n' mariadb-server mysql-community-server 2>/dev/null

아래의 MariaDB 관련 지침은 설치된 서비스가 MariaDB인 경우에만 사용하십시오. Oracle MySQL은 많은 경우 호환되는 것처럼 보이는 옵션 이름을 사용하지만, 패키지 구성, 서비스 이름, 사용 가능한 변수 및 기본값이 다를 수 있습니다. 설치된 MySQL 릴리스에 대한 자세한 내용은 설명서를 참조하십시오.

주요 참조 자료: Debian Bookworm의 default-mysql-server 패키지 및 MySQL 8.0 메모리 사용 설명서 .

OOM(메모리 부족)으로 데이터베이스가 다운되었는지 어떻게 알 수 있나요?

먼저 커널 메모리 부족으로 인한 프로세스 종료를 데이터베이스 오류, 서비스 재시작, 재부팅 또는 디스크 문제와 구분하십시오. 데비안 시스템에서는 journalctlsystemd의 저널을 읽습니다. 현재 부팅 로그를 검색하고 MariaDB 서비스 로그를 확인하십시오.

sudo journalctl -k -b --no-pager | grep -Ei 'out of memory|oom-kill|killed process'
sudo journalctl -u mariadb -b --no-pager -n 100
sudo systemctl status mariadb --no-pager

커널 로그 mariadbd에 mysqldOOM 메시지 이후에 특정 프로세스 이름이 기록되어 있다면 메모리 강제 종료(memory kill)가 발생했음을 알 수 있습니다. 일치하는 항목이 없는 경우 해당 서비스의 오류 로그와 공급자의 재부팅 또는 모니터링 기록을 확인하십시오. 저널링이 영구적으로 유지되지 않는 경우 재부팅 후 로그를 확인할 수 없으며, 관리형 VPS 공급자는 호스트 진단 정보의 일부만 제공할 수 있습니다.

서버가 유휴 상태일 때뿐만 아니라 실제 트래픽이 발생하는 동안 기준선을 수집하십시오.

free -h
swapon --show
vmstat 1
ps -eo pid,comm,rss,%mem --sort=-rss | head

`journalctl` 명령의 `swap-in` 및 `swap-out` 열을 주시하여 지속적인 스왑 인 및 스왑 아웃 활동을 vmstat확인 하십시오 . 스왑 할당량이 0이 아닌 것만으로는 문제가 되지 않지만, 지속적인 스왑과 느린 응답 시간이 함께 발생하면 메모리 부족을 나타냅니다. Linux는 메모리를 충분히 회수할 수 없을 때 최후의 수단으로 OOM(메모리 부족) 처리를 사용한다고 명시하고 있습니다. Linux 커널 메모리 관리 개념 및 Debian의 `journalctl` 설명서를 참조하십시오 .siso

튜닝하기 전에 무엇을 측정해야 할까요?

총 RAM 용량, 현재 및 최대 스왑 사용량, 가장 큰 상주 프로세스, 데이터베이스 연결 수, 웹 애플리케이션의 일반적인 최대 사용량을 기록합니다. 데이터베이스는 Debian, 웹 서버, 애플리케이션 워커, 모니터링 에이전트 및 파일 시스템 캐시와 메모리를 공유합니다. VPS는 호스트의 물리적 RAM보다 낮은 컨테이너 또는 cgroup 메모리 제한을 설정할 수도 있습니다. 데이터베이스 캐시 크기는 호스트의 총 메모리 용량보다 큰 값이 아니라 서비스에서 사용 가능한 메모리 제한에 맞춰 설정해야 합니다.

MariaDB의 경우 현재 메모리 관련 설정과 연결 피크를 확인하십시오.

sudo mariadb -e "SHOW VARIABLES WHERE Variable_name IN ('innodb_buffer_pool_size','max_connections','tmp_table_size','max_heap_table_size'); SHOW GLOBAL STATUS LIKE 'Max_used_connections'; SHOW GLOBAL STATUS LIKE 'Threads_connected';"

InnoDB 버퍼 풀은 테이블 및 인덱스 페이지를 캐싱합니다. 연결 제한과 쿼리 버퍼는 동시 작업량이 증가함에 따라 메모리 요구량을 증가시킬 수 있습니다. max_connections모든 버퍼가 항상 완전히 할당된 것처럼 연결별 버퍼 크기를 과도하게 늘리는 것은 피해야 하지만, 연결 제한이 너무 높으면 작업이 폭증할 위험이 있으므로 주의해야 합니다. MariaDB의 메모리 가이드에서는 전역 캐시, 연결별 버퍼 및 엔진 설정을 함께 조정하는 것을 권장하며, 특히 애플리케이션 연결 풀에 대해 언급합니다. MariaDB의 메모리 할당 가이드 와 연결 폭증 시 처리 가이드를 참조하십시오 .

소규모 VPS에서 MariaDB의 적정 규모를 어떻게 설정해야 할까요?

한 번에 한 가지씩만 변경하고, 원래 설정 파일의 사본을 보관한 다음, 재시작이 사용자에게 영향을 미치는지 유지 관리 시간 동안 테스트하십시오. Debian에서 제공하는 MariaDB 설정 파일에는 일반적으로 디렉터리 아래에 파일이 포함되어 있습니다 /etc/mysql/mariadb.conf.d/. 편집하기 전에 설치된 시스템의 활성 포함 디렉터리를 확인하십시오. 작은 드롭인 파일은 공급업체의 기본 파일을 교체하는 것보다 제거하기가 더 쉽습니다.

sudo cp -a /etc/mysql/mariadb.conf.d /root/mariadb.conf.d.backup
sudoedit /etc/mysql/mariadb.conf.d/90-low-memory.cnf

약 1GiB의 RAM을 가진 공유 VPS의 경우, 다음은 단지 신중한 시작 예시일 뿐이며 모든 환경에서 안전하게 사용할 수 있는 프로필은 아닙니다. 측정된 최대 메모리 사용량, 데이터베이스 크기, 작업 부하, 운영 체제 및 애플리케이션에 남은 RAM 용량을 기준으로 값을 낮추거나 높이십시오.

[mariadb]
innodb_buffer_pool_size = 192M
max_connections = 30
tmp_table_size = 16M
max_heap_table_size = 16M

MariaDB는 시작 시 옵션 파일에서 설정을 읽어옵니다. 사용 중인 버전에서 지원하는 섹션 이름과 유효 값을 확인하십시오. 이 파일이 로드되지 않으면 드롭인 파일을 제거하고 로그를 검토하십시오. 데이터베이스를 재시작하면 기존 연결이 중단되므로 적절한 시간에 재시작하십시오.

sudo systemctl restart mariadb
sudo systemctl is-active mariadb
sudo journalctl -u mariadb -b --no-pager -n 80
sudo mariadb -e "SELECT @@innodb_buffer_pool_size, @@max_connections;"

안정성과 서비스 품질 모두를 기준으로 결과를 판단하십시오. 버퍼 풀 크기를 줄이면 캐시 적중률은 낮아지고 디스크 읽기 횟수는 증가할 수 있습니다. 하지만 max_connections너무 줄이면 "연결 수가 너무 많습니다" 오류가 발생할 수 있습니다. Max_used_connections설정된 제한값과 비교하고 애플리케이션 풀 크기를 검토한 후 해당 제한값을 다시 변경하십시오. 정상적인 최대 트래픽 중에도 데이터베이스가 다운되거나 지속적인 디스크 스왑으로 인해 응답 시간이 저하되는 경우, 더 큰 RAM 계층으로 이동하거나 데이터베이스를 애플리케이션과 분리하십시오.

스왑을 사용하면 OOM(메모리 부족)으로 인한 크래시를 방지할 수 있습니까?

스왑은 Linux에서 일부 메모리 페이지를 이동하는 데 시간이 더 오래 걸리는 공간을 제공하며, 순간적인 부하 급증을 흡수할 수 있습니다. 하지만 스왑은 고속 RAM을 추가하거나 메모리 누수를 해결하거나 용량이 부족한 VPS를 지속적인 작업 부하에 적합하게 만들어주지는 않습니다. 스왑이 과도하게 발생하면 데이터베이스와 애플리케이션 모두 응답하지 않게 될 수 있습니다. 스왑 파일을 생성하기 전에 서비스 제공업체가 스왑 파일을 지원하는지, 그리고 VPS에 충분한 디스크 공간이 있는지 확인하십시오.

지원되는 경우 다음과 같이 1GiB 스왑 파일을 생성할 수 있습니다. 공급업체의 지침 및 사용 가능한 디스크 공간에 맞게 크기를 조정하고 각 명령의 결과를 확인하십시오.

sudo fallocate -l 1G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
swapon --show

재부팅 후에도 활성화하려면, /etc/fstab동일한 항목이 이미 있는지 확인한 후 다음 항목을 추가하십시오.

/swapfile none swap sw 0 0

그런 다음 해당 파일의 유효성을 검사 sudo findmnt --verify --verbose하고 파일이 에 나타나는지 확인하십시오 swapon --show. fallocate파일 시스템에서 지원되지 않거나 공급자가 스왑을 차단하는 경우 작업을 중지하고 공급자가 지원하는 절차를 사용하십시오. OOM 킬러를 비활성화하거나 MySQL에 극단적인 OOM 보호 점수를 부여하지 마십시오. 이는 메모리를 생성하지 않으므로 소규모 VPS의 나머지 부분을 더 큰 위험에 노출시킬 수 있습니다.

변경 사항이 효과가 있었다는 것을 어떻게 알 수 있나요?

최소한 한 번의 일반적인 사용량이 많은 기간 동안 VPS를 관찰하십시오. 유용한 결과는 다음과 같은 몇 가지 징후를 보입니다.

• 이전에 문제를 일으켰던 작업 부하 동안 새로운 커널 OOM-kill 항목이 발견되지 않았습니다.
• MariaDB는 활성 상태를 유지하며 재시작 횟수가 예기치 않게 증가하지 않습니다.
• vmstat 1일반적인 트래픽 상황에서는 지속적인 스왑인/스왑아웃이 표시되지 않습니다.
• 애플리케이션은 계속해서 응답성을 유지하고, 데이터베이스 연결 피크는 연결 오류 없이 새로운 제한치 이하로 유지됩니다.
• 백업이 완료되었으며 데이터베이스 쿼리는 애플리케이션에서 허용하는 지연 시간을 계속해서 충족하고 있습니다.

"서비스 시작"을 유일한 성공 기준으로 삼지 마십시오. MariaDB를 계속 실행 상태로 유지하면서 시스템을 끊임없는 스왑 작업으로 몰아넣는 설정은 근본적인 용량 문제를 해결하지 못합니다. 마찬가지로, 트래픽이 적은 하루만으로 월별 데이터 가져오기, 백업, 트래픽 급증 또는 아직 실행되지 않은 배치 작업의 성공을 보장할 수는 없습니다.

튜닝이 더 이상 적절한 해결책이 아닌 시점은 언제일까요?

적절한 캐시 및 동시성 조정 후에도 메모리 부족 현상이 지속되거나, 스왑 활동이 계속되거나, 쿼리 지연 시간이 허용할 수 없을 정도로 길어지거나, 애플리케이션이 반복적으로 새로운 연결 제한에 도달하는 경우, 더 큰 VPS를 선택하거나 워크로드를 분리하는 것을 고려해야 합니다. 데이터베이스 크기도 중요합니다. 버퍼 풀이 지나치게 작으면 메모리 사용량 급증은 피할 수 있지만 디스크 I/O가 새로운 병목 현상이 될 수 있습니다. 애플리케이션과 데이터베이스에서 급격하지만 예측 가능한 사용량 급증이 발생하는 경우, 먼저 애플리케이션이 과도한 연결을 열고 있는지 또는 메모리 사용량이 많은 작업을 동시에 실행하고 있는지 확인해야 합니다.

Debian의 기본 MariaDB 대신 Oracle MySQL을 사용하는 경우, 이러한 예제를 적용하기 전에 해당 서버의 버전별 설명서를 참조하여 서비스 이름, 옵션 파일 경로 및 메모리 변수를 확인하십시오. 두 엔진 모두 테스트된 백업을 보관하고 한 번에 하나의 변수만 변경하십시오. 이렇게 하면 Linux에서 OOM(메모리 부족) 처리가 절대 발생하지 않는다는 보장은 아니지만, VPS가 실제 최대 워크로드를 처리할 수 있는 충분한 여유 공간을 확보했으며 MySQL 또는 MariaDB가 더 이상 반복적인 문제의 원인이 아니라는 것을 확인할 수 있습니다.

추가 주요 참조 자료: MariaDB 시작 문제 해결 지침 (서버에 다른 엔진, 연결별 버퍼 및 운영 체제용 메모리도 필요하다는 내용 포함) 및 MySQL 8.0 참조 설명서 .