일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |
- Argos
- 우분투
- 밤랩
- unique result
- 스프링부트배포
- ubuntu
- jpa
- NonUniqueResultException
- 자바 롬복
- 회고
- 우테코
- @Modifying
- 벌크연산
- 우아한테크코스 블랙잭
- @Param
- 영속성컨텍스트
- 검색api
- bomblab
- 우아한테크코스
- @Query
- SpringDataJPA
- clearAutomatically
- docker에 ubuntu
- 배포스크립트
- BDDMockito
- 우아한테크코스5기
- 스프링 롬복
- ubuntu이미지
- Mock
- 레벨인터뷰
- Today
- Total
Jeomxon's Tech Note
AWS 우분투 인스턴스가 먹통이 될 때 본문
한 프로젝트를 하면서 aws로 우분투 인스턴스를 생성하여 서버를 사용하였다.
처음 aws를 사용하면서 많은 오류와 함께할 것이라 생각했지만 알 수 없는 이슈가 내 발목을 잡았다.
당연히 무료로 제공되는 인스턴스를 사용하여 사양이 부족했지만, 서버가 계속 먹통이 되는 것은 큰 골칫거리로 다가왔다.
구체적으로는 서버의 속도가 현저하게 느려져서 글자를 입력하거나 서버에 접속하려면 엄청난 시간을 기다려야했다.
지인들에게 자문을 구했으나 마땅한 해결방법을 얻지 못하였고, 지속적으로 찾아보던 중 아주 사소한 변화가 서버를 다시 사용하는데 큰 불편함이 없게끔 해주었다.
nohup라는 명령어를 통해 jar파일을 서버에서 실행했는데 내가 프로세스를 종료하지 않고 중첩해서 돌렸던 것이 문제가 됐던 것 같다.
간단하게 프로세스를 kill해주니 이전과 같이 자주 먹통이 되지는 않았다.
nohup java -jar -Duser.timezone=Asia/Seoul 파일명.jar &
이런 식으로 코드를 실행해줬는데 프로세스를 확인하고 끄지 않았던 것이다.
ps -ef | grep jar
서버에서 위와 같은 명령어를 통해서 실행중인 jar파일만 따로 프로세스를 확인하면
이런식으로 프로세스들이 뜨는데 여기서 내가 죽이려는 PID(프로세서 번호)를 확인할 수 있다.
첫번째 줄에 나와있는 jar파일의 프로세스 번호가 1030인걸 알 수 있다.
kill -9 1030
-9이라는 강제종료 옵션을 넣어서 1030프로세스를 종료시킨다. 즉 실행 중인 jar파일의 프로세스를 죽인다.
이후 다시 아래와 같은 명령을 통해서 새롭게 빌드해서 가져온 jar파일을 실행시키면 된다.
nohup java -jar -Duser.timezone=Asia/Seoul 파일명.jar &
이 문제는 CI/CD 파이프라인을 구축하지 않고, 로컬에서 jar파일을 빌드하여 서버로 보낼 때 사용했다.
서버에서 실행을 원했으므로 코드가 변경될 때 마다 계속 리빌드하여 서버에서 실행시키는 방식을 사용했기에,
그냥 인텔리제이에서 stop and run하는 그런 기능때문에 프로세스를 죽여야함을 간과했다.
사양이 남아도는 서버였으면 진작 찾지 못했을 것이라 오히려 다행이었다.
물론 앞으로 서버의 사양에 관계없이 프로세스를 확인하면서 실행하는 습관을 기를 수 있는 좋은 기회가 되었다고 생각한다.