1. 문제 상황
사이드 프로젝트 배포 서버로 EC2 t2.micro를 사용하고 있었다.
일반적인 API 테스트나 사용에는 큰 문제가 없었지만, 어느 날부터 배포할 때마다 지옥이 반복되기 시작했다.
- ssh로 첫 접속은 가능하지만
./gradlew clean build -x test명령어에서 무한 대기 현상- 다시 접속하려고 하면 SSH조차도 실패
- 결국 인스턴스를 재부팅 → 또 재접속 반복
프론트엔드 분께서 실수로 API를 짧은 간격으로 무한 호출하게 되면서,
서버가 다운 → 재부팅 → 또 무한 호출로 다운 → … 무한 루프 발생 😇
CPU 사용량 99% 고정
EC2 t2.micro는 1vCPU / 1GB 메모리의 매우 가벼운 인스턴스라서 바로 다운된다
2. 현재 메모리 사용량 확인
free -h
→ 물리 메모리 부족 + swap 부재 = OOM(Out Of Memory) 직전
(*) OOM 이란?
OOM (Out Of Memory) 은 시스템에 메모리가 부족하여
커널이 강제로 프로세스를 종료(Kill) 시키는 상황이다.
3. 해결 방향
swap 메모리 설정
(*) swap이란?
swap은 디스크의 일부 공간을 임시 메모리처럼 사용하는 공간이다.
실제 메모리가 부족할 때, 사용하지 않는 메모리 페이지를 swap으로 이동시켜
시스템 전체가 죽는 걸 방지해준다.
단점은 느리다.
(1) 스왑 파일 생성
sudo dd if=/dev/zero of=/swapfile bs=128M count=16
- dd : 파일을 생성하거나 복제
- if=/dev/zero : 입력 소스로 "0으로 채워진 바이트"를 사용한다. (zero 파일)
- of=/swapfile : /swapfile이라는 이름의 파일을 생성한다.
- bs=128M : 한 번에 128MB씩 데이터를 쓴다.
- count=16 : 총 16번 작성 → 128MB × 16 = 2GB의 파일 생성
즉, 0으로 채워진 2GB짜리 파일을 만들고 있는 것이다.
스왑 파일 크기 = 블록 크기 X 블록 수
시스템 RAM 용량이 2GB 이하일 때 권장 스왑 공간은 RAM 용량의 2배이기 때문에 사용 중인 EC2의 메모리가 1GB이므로, 스왑 메모리를 2GB로 설정한다.
(2) 읽기/쓰기 권한 제한
sudo chmod 600 /swapfile
(3) 스왑 영역으로 초기화
sudo mkswap /swapfile
→ 커널이 해당 파일을 swap 영역으로 인식할 수 있게 초기화한다.
(이 작업 없이는 /swapfile은 그냥 일반 파일이다.)
(4) 스왑 활성화
sudo swapon /swapfile
지금 만든 /swapfile을 실제로 swap으로 활성화하는 명령이다.
이 명령을 실행하면 운영체제는 이 공간을 부족한 메모리의 보조 수단으로 사용하게 된다.
(5) 확인
스왑 영역이 2GB 생긴 걸 확인할 수 있다!
-> 이후 바로 접속이 된다
