EC2
내에서 Spring Boot
를 로드하던 중 CPU 사용량이 기하급수적으로 상승하면서 EC2가 멈춰버리는 현상이 발생했습니다.
추가된 설정들이 존재했고 추가된 설정으로 인한 문제일 가능성이 높아 해당 설정들을 분석하였습니다.
spring:
hikari:
# 데이터베이스 연결의 수 제한
minimum-idle: 15
maximum-pool-size: 15
pool-name: DevLogHikariCP
max-lifetime: 200000
connection-timeout: 1000
server:
tomcat:
threads:
max: 200 # 생성할 수 있는 thread의 총 개수
min-spare: 10 # 항상 활성화 되어있는(idle) thread의 개수
accept-count: 100 # 작업큐의 사이즈
connection-timeout: 20000
추가된 설정들은 팀원분이 성능 테스트 과정에서 성능을 향상시키고자 추가했던 설정입니다.
스레드풀과 커넥션풀에 관한 설정으로 운영 단계에서는 문제가 발생할 수 있지만, 로딩 단계에서는 CPU의 문제를 일으킬 것 같지 않았습니다.
CPU의 문제가 아닌 다른 문제로 인해 CPU에 영향이 갈 것이라 판단했습니다.
현재 EC2
는 1CPU 1GiB 입니다. 메모리가 매우 작기 때문에 메모리로 인해 CPU의 사용률을 높일 가능성이 있습니다.
EC2
내에서는 Spring Boot
만을 실행합니다. Spring Boot
가 메모리 부족으로 실행하지 못하고 Context Switching
이 됩니다. 하지만 다음에 실행할 프로그램도 Spring Boot
입니다. 이 현상이 반복되고 CPU에 과부하가 올 수도 있겠다 생각했습니다.(Context Switching Overhead)
메모리로 인한 CPU 사용률 증가라면 메모리 공간을 확보하여 해결할 수 있습니다.
가설이 맞는지 스왑 메모리 영역을 확보하여 메모리 공간을 늘린 후 Spring Boot
를 다시 로드해보겠습니다.
# 2GB 크기의 스왑 파일을 생성
sudo fallocate -l 2G /swapfile
# 생성된 스왑 파일의 권한을 설정
sudo chmod 600 /swapfile
# /swapfile을 스왑 영역으로 설정
sudo mkswap /swapfile
# /swapfile 스왑 파일을 사용하도록 활성화
sudo swapon /swapfile
# /etc/fstab 파일에 스왑 파일에 대한 정보를 추가하여, 시스템 부팅 시 자동으로 스왑 파일을 활성화하도록 설정
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
# 현재 활성화된 스왑 공간의 목록을 표시
sudo swapon --show
# 시스템의 메모리 사용량을 표시
free -h
2기가의 메모리 공간을 확보 후 다시 Spring Boot
를 로드하면 정상적으로 실행됩니다.
CPU도 로드할 때 잠깐 2%로 올라갔다가 1%로 내려옵니다.
메모리 공간을 얼마나 사용하고 있는지 확인해보겠습니다.
free -h
사용중인 메모리만 1기가입니다. 메모리를 늘렸을 때 정상 작동을 하고 실제 CPU 사용률은 높지 않은 것을 보아 메모리 문제가 맞는 것 같습니다.
문제는 해결되었지만 어떤 설정이 메모리를 많이 잡아 먹는지에 대한 궁금증이 남아있습니다.
마지막으로 의심되는 설정을 소거 후 재로딩하여 메모리 사용률을 측정해보겠습니다.
스레드풀은 값을 설정하긴 했지만 애당초 기본값이므로 커넥션풀만 테스트하겠습니다.
minimum-idle
기본 값이 10이니 5개를 추가로 확보하였을 때 대략 80mb 라는 메모리를 잡아먹습니다.
생각보다 커넥션풀이 많은 메모리를 차지한다는 것을 알 수 있습니다.
추측과 문제 해결 과정을 통해 메모리 문제로 인한 CPU 사용률 증가라는 답을 도출했습니다. 정확한 테스트에 기반한 답이 아니라 아쉽지만, 알고있던 CS 지식을 활용하여 답을 찾아냈다는 점에서 의미가 있었다 생각합니다.
또한 실제 운영 환경에서는 Spring Boot
설정만으로 영향이 갈 수 있겠다는 생각이 들었습니다.