저사양 RAM VPS에서 Debian 12 사용 시 MySQL 메모리 부족 오류(OOM) 발생을 줄이는 방법

메모리가 부족한 Debian 12 VPS에서 OOM killer로 인해 MySQL이 중단될 위험을 줄이려면 원인을 확인하고, 모든 서비스에 메모리를 할당하고, 데이터베이스 동시 실행을 제한하고, VPS에서 허용하는 경우 스왑을 제공해야 합니다. InnoDB 버퍼 풀 크기를 줄이는 것만으로는 완벽한 해결책이 아닙니다. 스왑이나 OOM 보호 설정만으로는 과부하된 워크로드가 계속 실행될 것이라고 보장할 수 없습니다.

이 가이드는 2026년 10월 9일 Debian 12 “bookworm”, Linux 6.1 및 Oracle MySQL 8.0/8.4 문서를 사용하여 조사되었습니다. 아래 설정은 예시적인 시작점이며, 벤치마크 결과 또는 범용 구성이 아닙니다. 변경하기 전에 데이터베이스와 구성을 백업하고, 다운타임이 허용되는 시점에 데이터베이스를 재시작하도록 예약하십시오.

1. MySQL 설정을 복사하기 전에 서버를 확인하십시오.

확인됨: Debian 12의 기본 mysql-server 패키지는 MariaDB에 의존합니다. "MySQL"이 실행 중이라고 설명된 VPS가 실제로 MariaDB를 실행할 수도 있고, 다른 VPS는 별도의 저장소 또는 컨테이너에서 Oracle MySQL을 실행할 수도 있습니다.

mysql --version
systemctl status mysql mariadb

첫 번째 명령은 클라이언트를 식별하는 것이지 실행 중인 서버를 확실하게 식별하는 것은 아닙니다. 데이터베이스 관리자 계정으로 연결하여 다음 명령을 실행하십시오.

SELECT VERSION(), @@version_comment;

기존 인증 방법을 사용하십시오. Debian MariaDB 설치에서는 로컬 관리가 가능할 수 있습니다 sudo mysql. 서버 버전과 실제 서비스 이름을 기록해 두십시오. 이후 서비스 명령에는 mysql.service;를 사용하고 mariadb.service, 필요에 따라 대체하십시오. MariaDB 구성에 Oracle 전용 변수를 추가하지 마십시오.

2. 시스템 종료가 메모리 부족(OOM)으로 인한 것인지 확인합니다.

흔히 잘못 알려진 사실: 원인을 알 수 없는 데이터베이스 재시작은 모두 메모리 부족으로 인한 서비스 중단(OOM)으로 이어진다는 것입니다. 인증 오류, 디스크 용량 부족, 잘못된 구성, 시스템 충돌 및 관리자 재시작 또한 서비스 중단을 초래할 수 있습니다.

sudo journalctl -k -b
sudo journalctl -u mysql.service --since today
sudo journalctl -u systemd-oomd --since today

오류 발생 시간대 주변의 커널 메시지에서 메모리 부족 오류와 종료된 프로세스를 찾아 서비스 로그와 비교해 보세요. 패키지가 저널이 아닌 파일에 오류 메시지를 기록하는 경우 데이터베이스 오류 로그도 확인하십시오. 재부팅 전에 오류가 발생한 경우, journalctl -k -b -1보존된 로그가 있는 이전 부팅 시점을 확인하세요. 과거 로그가 누락된 경우 원인을 확인할 수 없습니다.

사용자 공간 관리자는 워크로드를 종료할 수도 있습니다. Debian의 systemd-oomd 매뉴얼은 커널 OOM 이벤트 발생 전 메모리 부족에 따른 개입 방법을 설명합니다. 모든 Debian VPS에서 systemd-oomd가 사용된다고 가정하기보다는, 해당 시스템이 설치되어 있고 활성화되어 있는지 확인하십시오.

systemd 제한 사항도 확인하십시오.

systemctl show mysql.service \
  -p ControlGroup -p MemoryCurrent -p MemoryHigh \
  -p MemoryMax -p MemorySwapMax

cgroup v2 시스템에서는 보고된 ControlGroup 경로를 사용하여 아래의 memory.events, memory.max, 및 값을 확인하십시오. 상위 cgroup도 확인해야 합니다. Linux cgroup v2 설명서에서 이러한 카운터와 제한 사항에 대해 자세히 설명합니다. 호스트에 메모리 용량이 충분하더라도 cgroup은 허용된 메모리를 초과할 수 있습니다. 카운터는 종료 횟수를 기록하지만, 원인을 파악하려면 제한 사항 및 로그와 함께 해석해야 합니다.memory.swap.max/sys/fs/cgroupoom_kill

3. 버퍼 풀뿐만 아니라 VPS 전체를 측정하십시오.

free -h
ps -eo pid,comm,rss --sort=-rss
vmstat 1

정상적인 트래픽과 장애 발생 시 관련된 작업들을 관찰하여 데이터를 수집하십시오. ` freerecess` 열뿐만 아니라 `available memory`에도 집중하십시오. 데비안의 무료 매뉴얼 에서는 사용 가능한 메모리를 스왑 없이 사용할 수 있는 용량의 추정치로 설명합니다. 프로세스 목록의 `response` 값은 KiB 단위이므로, 이를 더하면 공유 메모리가 중복 계산될 수 있습니다.

확인됨: MySQL은 InnoDB 버퍼 풀 외에도 연결 및 쿼리 관련 할당을 포함하여 메모리를 할당합니다. MySQL 메모리 사용량 참조 문서에서 이러한 구성 요소를 확인할 수 있습니다. 구성된 버퍼를 기반으로 하는 공식은 정확한 상한값이 아닌 계획 추정치로 간주해야 합니다.

조치: 커널, 웹 워커, 모니터링, 백업 및 임시 데이터베이스 작업을 위한 여유 공간을 확보하십시오. InnoDB에 대부분의 RAM을 할당하라는 일반적인 조언은 공유 VPS 환경에서는 조정 없이는 적합하지 않습니다. PHP 워커 또는 빌드 작업이 사용 가능한 여유 공간을 많이 소모하는 경우 MySQL의 용량을 반복적으로 줄이는 대신 해당 워크로드를 조정하거나 다른 곳으로 이동하십시오.

4. 스왑 공간을 RAM 대체가 아닌 버퍼로 추가하십시오.

상황에 따라 다릅니다. 스왑은 일시적인 익명 메모리 부하를 일부 흡수할 수 있지만, 지속적인 스왑 사용은 쿼리 속도를 지나치게 느리게 만들 수 있습니다. 컨테이너 기반 VPS는 스왑 사용을 제한할 수 있으며, 서비스는 MemorySwapMax호스트에 스왑 공간이 있더라도 스왑 사용을 차단할 수 있습니다.

swapon --show
free -h
df -h /
findmnt -no FSTYPE /

스왑 파일이 없고, 시스템 제공업체에서 스왑 파일 생성을 허용하며, 디스크 여유 공간이 충분한 경우, 다음 명령어를 사용하여 ext4와 같은 적절한 로컬 파일 시스템에 1GiB 크기의 스왑 파일을 생성할 수 있습니다. /swapfile 디렉터리가 이미 존재하는 경우에는 이 명령어를 실행하지 마십시오. 먼저 파일 시스템별 요구 사항을 확인하십시오. Btrfs 파일 시스템은 쓰기 시 복사 방지(no-copy-on-write) 스왑 파일 설정이 필요합니다.

sudo dd if=/dev/zero of=/swapfile bs=1M count=1024 status=progress
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
swapon --show

활성화가 성공한 후에만 이 항목을 한 번 추가하십시오 /etc/fstab.

/swapfile none swap sw 0 0

Debian swapon 매뉴얼에는 스왑 파일 제약 조건이 명시되어 있습니다. VPS 환경에서 활성화가 거부되는 경우, 공급업체에 지원되는 스왑 용량에 대해 문의하거나 요금제의 메모리 용량을 늘리십시오. 설정 실패는 그대로 두지 마십시오.

"swappiness 값을 0으로 설정"하는 트윅을 OOM(메모리 부족) 방지용으로 복사하지 마십시오. 커널 VM 문서에서는 swappiness를 메모리 회수 비용 선호 사항으로 정의합니다. 이는 메모리를 생성하거나 데이터베이스 메모리 제한을 부과하지 않습니다. 처음에는 변경하지 않고 동작을 측정하십시오.

5. 적절한 데이터베이스 기준선을 설정하십시오.

예를 들어, 소규모 InnoDB 워크로드와 몇 개의 애플리케이션 워커를 사용하는 1GiB VPS를 생각해 보겠습니다. 다음 값들은 평가 대상이 될 수 있는 값일 뿐, 해당 워크로드가 적합하다는 증거는 아닙니다.

[mysqld]
innodb_buffer_pool_size=128M
max_connections=20
tmp_table_size=16M
max_heap_table_size=16M

서버 옵션은 설치 패키지에 포함된 설정 파일에 추가하십시오. Oracle MySQL 패키지에는 해당 파일이 포함될 수 있으며 /etc/mysql/mysql.conf.d/, Debian MariaDB는 일반적으로 해당 파일을 사용합니다 /etc/mysql/mariadb.conf.d/. 기존 include 지시문을 확인하고 백업을 만들어 두십시오. MySQL의 옵션 파일 관련 문서에서 서버 옵션 그룹 및 파일 처리 방법에 대해 자세히 설명합니다.

128MiB 버퍼 풀은 전체 데이터베이스 메모리가 아닌 캐시 메모리를 제한합니다. 여러 애플리케이션 인스턴스가 각각 풀을 유지하는 경우 연결 제한을 20으로 설정하는 것은 너무 제한적일 수 있습니다. 반대로, 20개의 동시 실행 부하가 큰 쿼리는 VPS에 과부하를 줄 수도 있습니다. 애플리케이션 풀 총 용량을 서버 제한보다 낮게 유지하고 관리자 액세스를 위한 여유 공간을 확보하며, 연결 거부 여부를 확인하십시오.

위의 공통 변수들은 MariaDB의 시스템 변수 참조 에도 나타나지만 , 임시 테이블의 동작은 제품 및 버전에 따라 다릅니다. 시스템 환경이 제한된 경우, 성능 향상을 위한 일반적인 해결책으로 전역 정렬, 조인 또는 읽기 버퍼 크기를 늘리는 것은 권장하지 않습니다.

6. 임시 테이블과 동시성을 함께 관리하세요

흔히 오해하는 점: 이 설정은 tmp_table_size=16M모든 쿼리 메모리를 16MiB로 제한하는 것이 아닙니다. 여러 세션, 여러 임시 테이블 및 기타 실행 할당이 공존할 수 있습니다.

Oracle MySQL 8.4 의 경우 , 추가적인 예시 시작점은 다음과 같습니다.

temptable_max_ram=64M
temptable_max_mmap=0

제품 지원 여부를 확인한 후에만 기존 [mysqld]그룹에 이러한 설정을 추가하십시오. 이 설정은 TempTable 엔진의 공유 RAM 임계값과 메모리 매핑 임시 파일 사용량을 제어합니다. 전체 mysqld 프로세스 또는 모든 스레드 로컬 할당량을 제한하는 것은 아닙니다. 임계값을 낮추면 더 많은 작업이 디스크에 저장될 수 있습니다.

MySQL 8.4 임시 테이블 관련 문서에서 이러한 제한 사항을 설명합니다. MySQL 8.0은 버전에 따라 동작 방식이 다릅니다. 해당 제한 사항은 temptable_max_mmap8.0.23 버전에서 도입되었고, 8.0.28 버전부터는 개별 TempTable에 대한 제한 사항이 되었습니다. 동일한 설정을 적용하기 전에 MySQL 8.0 참조 문서를tmp_table_size 확인하십시오 . 이러한 Oracle 관련 옵션을 MariaDB에 복사하지 마십시오.

조치: 중복되는 보고서 쿼리, 백그라운드 작업자, 백업 또는 가져오기 작업을 제한하십시오. 특정 작업으로 인해 부하가 발생할 경우 쿼리 계획과 인덱스를 검토하십시오. 부하가 큰 작업을 트래픽이 집중되는 시간대에서 벗어나도록 이동하면 도움이 될 수 있습니다. 정상적인 동시 접속 수요가 여전히 용량을 초과하는 경우, RAM을 추가하거나 데이터베이스를 분리하는 것이 적절한 다음 단계입니다.

7. 변경 사항을 검증하고 의도적으로 재시작하십시오.

이 옵션을 지원하는 Oracle MySQL 버전의 경우, 재시작하기 전에 구성을 확인하십시오.

sudo mysqld --validate-config

서비스가 기본 구성 검색을 사용하지 않는 경우, 서비스와 동일한 기본 파일 경로 및 관련 시작 인수를 사용하십시오. MySQL 유효성 검사 참조 문서에 따르면 유효성 검사는 모든 하위 시스템을 초기화하지 않습니다. 유효성 검사를 통과하는 것은 워크로드 용량 테스트가 아닙니다. MariaDB가 이 Oracle 옵션을 지원한다고 가정하지 마십시오.

계획된 시간 내에 실제 서비스를 재시작한 다음 시작 과정을 검사하고 유효값을 조회합니다.

sudo systemctl restart mysql.service
systemctl status mysql.service
sudo journalctl -u mysql.service --since today

SHOW GLOBAL VARIABLES WHERE Variable_name IN
('innodb_buffer_pool_size','max_connections','tmp_table_size',
 'max_heap_table_size','temptable_max_ram','temptable_max_mmap');
SHOW GLOBAL STATUS WHERE Variable_name IN
('Threads_connected','Threads_running','Max_used_connections');

지원되지 않는 변수는 결과에 나타나지 않습니다. 새 파일이 우선 적용된다고 가정하지 말고 의도한 설정을 확인하십시오. 변경 사항으로 인해 시작이 실패하는 경우 저장된 구성을 복원하거나 새 재정의만 제거한 다음 다시 시작하십시오. 진단을 위해 오류 세부 정보를 보관하십시오.

8. 대표적인 부하 조건에서 성공을 정의하십시오.

free -h
vmstat 1
cat /proc/pressure/memory

변경 전후의 동일한 트래픽과 예약된 작업을 비교하십시오. 새로운 OOM 이벤트, 데이터베이스 재시작, 사용 가능한 메모리, 연결 거부, 스왑 활동 및 쿼리 지연 시간을 추적하십시오. 특히 vmstat지속적인 스왑 인/스왑 아웃은 조사할 필요가 있습니다. Debian vmstat 설명서에 따르면 첫 번째 보고서는 부팅 이후 활동의 평균을 나타내며, 현재 속도를 확인하려면 이후 보고서를 사용하십시오.

커널 PSI 참조 문서에서는 압력 스톨 측정 방법을 설명합니다. 메모리 스톨 시간을 늘리면 추가 시스템 종료 전에도 문제가 발생할 수 있음을 알 수 있습니다. 유휴 시스템이 10분 동안 작동한다고 해서 다음 백업이나 트래픽 급증이 안전하다고 보장할 수는 없습니다.

문제를 악화시킬 수 있는 오해들

Debian의 systemd 리소스 제어 매뉴얼 에 따르면 MemoryMax유닛 내에서 OOM(메모리 부족) 처리를 호출할 수 있습니다. 공급자 또는 컨테이너 제한을 맹목적으로 제거하지 마십시오. 애플리케이션에는 해당 제한에 맞는 메모리 예산이 필요하거나, 제한 용량 변경에 대한 승인이 필요합니다.

이 특정 워크로드가 실행될 수 있도록 보장하는 최소 VPS 크기는 검증된 바가 없습니다. 유용한 처리량을 위해 지속적인 스와핑이 필요하거나, 예약된 작업이 여전히 프로세스를 종료시키거나, 캐시 크기가 작아 지연 시간이 허용할 수 없을 정도로 높다면, 구성을 용량 대체 수단으로 생각하지 마십시오. RAM을 업그레이드하거나, 애플리케이션 동시 실행 수를 줄이거나, 데이터베이스를 별도의 서비스로 이동하십시오.