티스토리 뷰
발단
나는 회사에서 개발 외에 운영업무도 맡고 있는데, 어느날 고객사로부터 우리 서버가 메모리를 과도하게 사용하고 있다는 알림이 왔다고 전해들었다. 그래서 문제의 원인이 우리가 개발한 소스인지 아니면 그외의 원인이 있는 것인지 확인하기 위해 서버에 접속했다.
전개
우선은 제일 먼저 한 일은 우리가 개발한 애플리케이션이 실제로 메모리를 과도하게 사용하고 있는지 보는 것이다.
ps -ef --sort -rss
위 명령어를 사용하면 메모리를 많이 사용하는 순으로 볼 수 있다. 또, top으로도 확인할 수 있다. 이때 shift + M을 누르면 메모리 사용 내림차순으로 정렬해서 볼 수 있다. 주의해서 봐야할 것은 RES이다.
또, 해당 프로세스에 대한 정보를 확인하기 위해 아래의 명령어를 이용하여 정보를 확인했다.
vi -R /proc/[PID]/status
위 명령어로 프로세스에 대한 정보를 확인할 수 있는데, VmRSS 항목은 할당된 메모리 크기를 나타낸다. 예시로 다른 개발계 VM에서 확인했을 때, top 명령어로 확인한 tomcat의 메모리 사용량은 1.4G정도였는데, /proc/[PID]/status로 확인한 할당된 메모리 크기는 1.46G였다.
그리고 GC 로그를 살펴봤다. 아래는 임시 VM에서 확인한 GC 로그이다. 중간에 보면 422635.283으로 시작하는 부분이 있는데, 이 422635.283은 JVM 시작 이후 시간이고, 그 다음 [GC (Allocation Failure ~ 으로 GC 유형, CG가 발생한 이유를 나타낸다.
이때, Full GC만 보고 싶다면 간단히 'Full GC'로 검색하면 된다.
결말
사실 이 이슈는 전에도 한 번 발생했었다. 그때는 대리님이 나보다 훨씬 많은 분석을 하셨고, 그 결과 우리 시스템에는 문제가 없다고 결론이 났는데 이번에 또 발생한 것이다. 물론 원인은... 알 수 없었다. 다음번에 또 발생하면 그땐 분석하는데 문제없게 GC로그를 익는데 익숙해지고, top 명령어의 결과를 살펴보는데 문제가 없게 익숙해지는 것이 관건이겠다.
'업무 경험 및 성과' 카테고리의 다른 글
비동기작업이 끝났는지 CountDownLatch로 확인하기 (0) | 2023.06.19 |
---|---|
산출물 취합에서 공동작업으로, 시간 절약 (0) | 2023.03.26 |
같은 예외일 때 뷰나 데이터를 내려주는 분기처리에 대한 고민 해결 (0) | 2023.01.17 |
POI로 엑셀 데이터 유효성 검사(드롭다운) 기능 추가시 주의사항 (0) | 2022.12.13 |
AWS CodeDeploy에서 BeforeInstall단계 UnknownError 해결 (0) | 2022.11.13 |