Contents
- 시작하기
- 진행 내용
- 테스트 : Run
- 테스트 지표 분석 : 전체
- 테스트 지표 분석 : JVM Heap
시작하기
이번 블로그에서는 JVM 메모리 영역을 확장해서 성능 개선 여부를 확인해보겠습니다. 상황은 이렇습니다.
- 처리하는 Requests Per Second가 더 이상 증가하지 않는 시점에 JVM Heap 영역 사용량은 최대치까지 올라갔다.
- CPU가 Garbage Collection 에 필요 이상의 시간을 소비하는 것으로 보인다.
- JVM의 메모리를 기본설정보다 높게 잡아보자.
진행 내용
개선사항
- -Xms1024 m: 시작 힙 메모리 사이즈에 처음부터 1GB를 할당
- -Xmx2048 m: 최대 힙 메모리 사이즈를 2GB로 설정
기대하는 결과는?
- 시작부터 힙 사이즈를 크게 설정하면 GC 발생빈도가 하락하고 CPU가 클라이언트 요청을 처리하는 데에 더 많이 사용할 수 있을 것
걱정되는 부분은?
- GC 발생 빈도가 하락하겠지만 GC 한 번에 처리해야 하는 메모리가 많아져 한정된 CPU에게 부담이 되지 않을까?
테스트 : Run
테스트를 실행해봅니다. 테스트는 21분 동안 0/s부터 1000/s까지 linear 하게 증가하는 트래픽을 발생시킵니다.
테스트 지표 분석 : 전체
성능개선 적용 전(Left)과 후(Right)의 결과 차이입니다. 자세히 보지 않아도 큰 변화가 없다는 것을 알 수 있습니다. 테스트의 의도는 여유로운 힙 메모리 크기를 통해 GC 발생 빈도를 줄이고 요청 처리를 위한 CPU 사용량을 증가시키는 것이지만 효과가 없습니다. JVM Heap 관련해서 한번 짚고 가겠습니다.
테스트 지표 분석 : JVM Heap
JVM Heap 그래프에서 주목할 부분은 변동 트렌드입니다. 미리 설명하자면 테스트에서 트래픽은 계속 증가하게 설정했으니 Heap 사이즈가 증가세인 것은 불가피합니다. 하지만 그와는 별개로 Heap 사이즈 증가 트렌드가 다른 패턴을 나타내고 있습니다.
- Before : 좌측(Before) JVM Heap 그래프에서는 400 TPS 근처에서 두배 가까이 빠르게 증가합니다.
- After : 메모리를 여유롭게 잡은 우측(After) 케이스의 그래프를 보면 완만한 상승세를 나타내고 있습니다.
사전에 미리 JVM 힙 메모리를 여유롭게 설정하는 것은 메모리 문제가 상대적으로 느리게 발생되게 하는 방법이 될 가능성도 있습니다. 외부 변수들을 최대한 격리시키고 A/B 테스트를 여러 번 진행하면 차이가 확실히 드러날 것으로 보입니다.
서버에서 사용 중인 JVM이 힙 메모리 영역의 부분들을(Eden, Survivor, etc..) 어떠한 비율로 나누고 유지하는지, 그리고 어떤 횟수/조건을 기준으로 확장하는지를 파고들면 유익한 인사이트가 나올 것으로 예상됩니다.
하지만 아직 성능개선 포인트가 몇 가지 더 남아있기 때문에 이 부분은 시간이 되면 별도로 다루도록 하겠습니다.
'in-bob-we-trust' 카테고리의 다른 글
테스트를 작성하고, 커버리지를 95% 이상 유지하며 깨달은 것들 (테스트 철학, 전략, 노하우, Jacoco) (0) | 2022.01.31 |
---|---|
서버 성능테스트 이야기 4 [ 성능개선 적용기 : StackTrace 최소화 ] (0) | 2022.01.28 |
서버 성능테스트 이야기 2 [ 첫 테스트 ] (0) | 2022.01.28 |
서버 성능테스트 이야기 1 [ Overview ] (0) | 2022.01.26 |
프로젝트 비용 최적화를 위한 Reactive + MongoDB Atlas Serverless 적용 및 예시 (Spring Webflux) (0) | 2022.01.25 |