최근에 나에게 일어난 트러블인데 이와 관련된 글이 잘 보이지 않아 비슷한 고민을 하고 있는 사람들을 위해 글을 남겨두려고 한다.
이 글을 찾은 사람들 중 다음과 같은 상황이라면 도움이 될 수도 있을 것 같다.
- usage of memory가 가득찼다!
- 배포만 하고 가만히 두었는데 메모리 용량이 가득찼다!
- No space left on device 에러가 발생한다!
진짜 프로젝트를 하면서 정말 시간을 많이 잡아 먹었던 부분이어서 꼭 글로 남겨야겠다고 생각했다.
(잘못된 글일수도 있으니 참고만 해주시고 지적이나 조언 해주시면 감사하겠습니다!)
최근들어 이전의 개발한 서비스들의 유지보수를 하고 다시 빌드를 하려고 할 때, "no space left on devide" 라는 에러가 뜨면서 빌드가 되지 않았다. 해당 프로젝트의 경우 패키지 매니저로는 yarn을, 프로세스 매니저로는 pm2를 사용했다.
분명 내가 인스턴스에서 한 것 이라곤 git pull 받아와서 build하고 pm2로 돌아가게 하는 것 뿐이였는데 왜 용량이 가득 찼는지 의아했다.
처음엔 로그가 쌓여 그런 것인지 알고 구글링을 통해 /var/log에 가서 로그를 지워보라길래 해보았다.
하지만 한 두번은 가능했으나 이후 log를 지워도 더이상 용량이 나지 않았다.
실제로도 /var/log 폴더가 용량에 차지하는 비중은 높지 않았다.
// 용량 확인
$ df -h // 시스템 디스크 사용 현황 확인
$ du -sh * // 현재 폴더 내의 디렉토리 및 파일의 용량 확인
// 폴더 이동 및 삭제
$ cd /var/log // /var/log폴더 이동
$ sudo rm -rf [파일명] // 특정 파일 삭제 (주로 syslog, kern.log 등등..)
애초에 인스턴스에 부여된 볼륨의 크기가 8GB 밖에 되지 않아서 서비스가 더 많은 스토리지를 필요로 하고 있구나 라고 생각했다.
그래서 해당 에러를 해결하기 위해 볼륨크기를 늘려주면 되겠다 생각하였고 실제 프로젝트의 크기는 700MB 정도였기 때문에 많은 용량이 필요하지 않을 것이라 생각하여서 2GB 정도만 우선 늘려주었다.
(만약 EC2의 볼륨을 늘릴 생각이라면 다음 글들을 참고하면 도움이 될 것이다 -> 글1, 글2)
하지만 이틀 정도 뒤에 다시 같은 문제가 발생하였다.
그래서 원인을 알아보기 위해 chatGPT와 열심히 구글링을 해보며 파일 정리는 다 해보았지만 명확한 원인을 파악하진 못하였다.
계속 든 의문점은 다음과 같았다.
내 파일은 700MB정도 밖에 안 드는데 대체 /dev/root 안의 뭐가 그렇게 많은 용량을 차지할까? 였다.
그래서 /dev 폴더로 들어가 봤지만 파티션들만 있을뿐 명확한 해답을 얻기 힘들었다.
내가 터미널을 통해 주로 하는 일이 yarn build 밖에 없는데 왜 이런일이 발생하지 라고 세상을 원망하고 있었는데, 이때 빌드 과정에서 캐쉬가 쌓이나? 다른 곳에 로그가 남나? 라고 생각하면서 아래 명령어를 입력하니 묵은때 씻겨나가듯 해결되었다.
yarn clean cache
명확한 원인은 아직 잘 모르겠으나 가설은 다음과 같다.
- yarn build를 할때 마다 캐쉬가 축적된다. (이전의 빌드한 파일을 지우지 않다보니 캐쉬가 누적되고 있다.)
- nuxt3를 이용한 SSR 프로젝트이다 보니 페이지에 대한 캐쉬가 내부적으로 축척된다.
아마 1,2번 복합적으로 일어나는게 아닐까 싶긴한데 나중에 조금 더 알아봐야겠다.
추가적으로, 만약 공간 확보를 하다가 명령어 하나 실행할 용량도 남지 않았을 경우 다음 명령어를 실행해보자.
$ sudo mount -o size=10M,rw,nodev,nosuid -t tmpfs tmpfs /tmp
위의 명령어는 tmpfs 파일 시스템을 /tmp 디렉토리에 마운트하는 명령어다.
tmpfs는 임시 파일 시스템으로, RAM을 사용하여 파일을 저장하는데 사용되는데 약간의 공간을 마련하는데 도움을 준다.
+ 240725 추가글
오늘 드디어 이 글의 마무리를 지을 수 있을 것 같다.
오랜만에 들어간 인스턴스는 다시 용량이 가득 찬 상태로 나를 반겨주었다..ㅎㅎ
하지만 이번에는 yarn cache clean 으로도 용량이 생기지 않아서 이것 저것 삭제해 보다가 근본적인 원인을 찾지 않으면 영원히 고통받을 것 같다는 생각에 삽질을 해보게 되었고 해결하였다!
문제는 결국 인재였다.
내 프론트 프로젝트의 용량은 700mb 남짓인데 왜 /dev/root의 용량이 GB단위로 차지 하는가에 대한 의문은 결국 로그와 캐쉬 때문인게 맞았다.
yarn build를 통해 생긴 캐쉬들과 pm2 start를 하며 생긴 로그들이 .으로 숨겨진 파일 내부에서 엄청난 용량을 차지하고 있어서 파악하기 어려웠던 것이였다.
$du -sh *
해당 명령어는 숨김처리된 폴더에 대해선 알려주지 못한다.. 그래서 구글링을 통해 찾아본 명령어를 쳐보니 우연히 용량의 근원지를 알게 되었다...
$sudo du -x -h / | sort -h | tail -40 | sort -h -r // 루트 디렉토리 아래의 용량 차지 상위 순서대로 디렉토리 리스트를 구함
pm2의 log 폴더 내에서 특히 yarn-preview-out.log라고 하는 파일이 가장 많은 용량을 차지 하였는데, 이는 주로 yarn preview 명령을 실행했을때 서버 실행중 발생하는 로그들을 기록하는 부분이라고 한다..
즉, 내가 무심결에 작성해둔 console.log와 같은 부분들이 로그로 빼곡히 남고 있던 중이였다...
그래서 아래의 명령어를 통해 yarn-preview-out.log을 비워 주었고 용량의 60%를 save할 수 있었다.
sudo truncate -s 0 yarn-preview-out.log
# 또는
echo "" > yarn-preview-out.log
이번 사건을 통해 얻게된 교훈은.. console.log 같은 부분은 남겨두지 말고 제때 삭제 하자는 것과 더 큰 후환을 막기 위해 항상 근본적인 원인을 해결할 수 있도록 하자는 것이다.
'Programming' 카테고리의 다른 글
| 내가 생각하는 프로젝트 규모에 따른 프론트 기술스택 선정기준 (0) | 2024.08.24 |
|---|---|
| [Webflow] Scroll into view 애니메이션이 한 번 밖에 실행이 안될때 (0) | 2024.07.13 |
| Vue 프로젝트 투입 하루 전 읽어볼 글 (0) | 2024.03.21 |
| 간단한 프로젝트에서 쓰기 좋은 Git Branch (Git Workflow) 전략 (1) | 2023.12.20 |
| CI / CD 개발 프로세스가 뭘까? (0) | 2023.01.10 |