신규 프로젝트를 위한 환경 세팅 중에 있다. EC2 레지스트리에 이미지를 올리고 워크플로우에서 이미지를 pull받아 jar를 동작시킬 컨테이너를 생성할 계획이다. 이미 기존 EC2에 다른 프로젝트 상용배포된 컨테이너가 하나 동작중이고, 신규로 JAR 하나를 더 컨테이너로 동작시킬 계획이다.
self-hosted runner를 ec2에 설치하고 jar가 잘 돌아갈지 검증하기 위해 ec2의 메모리를 확인해봤다.

프리티어가 아닌 EC2 임에도 가용가능한 메모리가 800MB 조금 넘게 남아있었다. JAR를 하나 더 돌리기엔 턱없이 부족한 상황이다. 아마 상용배포된 기존 프로젝트의 잔해물이 곳곳에 흝어져있으리라 생각하고, 버퍼/캐시 용량을 최대한 줄여보려고 한다. 원래 리눅스 계열이 파일시스템에서 메모리가 많이 잡아먹는다는건 예전부터 들어왔다.
*
리눅스에서는 기본적으로 디스크 상의 파일을 읽고 난 뒤 (I/O입출력) 닫아도 메모리가 모두 반환되지 않습니다.
그 이유는 파일의 정보를 다음 사용해 대비하여 cache 하기 때문입니다.
따라서 대용량의 파일이 관리되는 서버는 캐시의 적중률이 낮게 되기 때문에 cache기능을 끄거나 주기적으로 캐시를 지워주어야 합니다.
일단 불필요한 라이브러리부터 제거해보았다.

약 100mb 정도 정리가 된걸 확인했다. 그래도 여전히 jar를 하나 더 돌리기엔 메모리가 부족하다! runner도 아직 설치를 안한 상황이다.
버퍼 캐시를 삭제하는 명령어이다.
sudo sysctl -w vm.drop_caches=2

이 행동의 결과로 캐시 히트률이 급격히 떨어질테니 그때마다 부수적인 메모리 사용이 늘어날 수도 있다. 그렇기 때문에 여유분의 메모리를 남겨두는 것을 목표로 하고 runner와 jar를 기동시켜 활용해보겠다.
'Backend' 카테고리의 다른 글
| Logback Rolling file appender 적용 (Docker volume mapping, Springboot ) (0) | 2024.12.30 |
|---|---|
| CICD 환경변수 문제 기록 (github actions, docker, ECR) (3) | 2024.12.29 |
| [CI/CD] github self-hosted runner로 ec2 배포하기 (2) | 2024.12.26 |
| Sentry Slack 연동 ( 에러 메세지 모니터링 통합 ) (1) | 2024.09.22 |
| [Springboot] OAuth2.0 도입 - RestTemplate, FeignClient 비교 (1) | 2024.07.28 |