Visual VM과 nGrinder를 사용한 모니터링과 부하 테스트

개발자에게 장애 상황에 대한 판단 및 해결 조치는 매우 중요합니다.

이 글에서는 장애 상황을 판단하는 방법에 대해 알아보고자 합니다.

웹 애플리케이션에서 장애 상황은 크게 2가지로 구분할 수 있습니다.

1. JVM 관련
2. Network 관련

이번에는 각각을 모니터링 및 테스트 하기 위하여 Visual VM과 nGrinder를 활용하여 보겠습니다.

 

https://liltdevs.tistory.com/167

JMX 와 VisualVM 그리고 Heap dump 분석하기

https://liltdevs.tistory.com/169

nGrinder 설명과 사용법 정리

 

예제 코드

 

package com.example.load;

import lombok.RequiredArgsConstructor;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.stereotype.Service;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

import java.util.ArrayList;
import java.util.List;

@Service
class Container {
	List<SomeObj> container = new ArrayList<>();
}
class SomeObj {
	private int a;

	public SomeObj(int a) {
		this.a = a;
	}
}

@RequiredArgsConstructor
@RestController
class TestController {
	private final Container container;
	private static int cnt = 0;

	@GetMapping
	public String test() {
		List<SomeObj> temp = new ArrayList<>();
		for (int i = 0; i < 1000; i++) {
			temp.add(new SomeObj(1));
		}
		container.container.addAll(temp);
		return "hi";
	}
}

@SpringBootApplication
public class LoadTestApplication {

	public static void main(String[] args) {
		SpringApplication.run(LoadTestApplication.class, args);
	}

}

 

저희가 원하는 상황은 다음과 같습니다.

• 리퀘스트가 들어올 때마다 객체를 List에 담습니다.
• 이렇게 담긴 객체를 해제되지 않도록(가비지 컬렉터가 해제하지 않도록) 싱글톤인 Container에 담아 둡니다.
• 그리고 Out Of Memory 가 발생했을 때 모니터링 툴을 이용하여 상황을 판단합니다.

 

 

이를 위해 nGrinder 의 설정은 간단하게 해줍니다.

5명의 유저가 부하를 발생시킬 예정입니다.

그리고 사전에 Spring과 VisualVM 을 켜두고 확인합니다.

 

 

테스트 결과를 보니 뭔가 테스트가 정상적으로 작동하지 않을 것을 확인할 수 있습니다.

Duration 으로 1분동안 request를 보냈지만 성공한 개수는 불과 3개 뿐입니다.

심지어 Error도 1건이 발생되었습니다.

 

 

다시 VisualVM 으로 돌아와 확인해보니, 원하는 결과를 얻었습니다!

Heap Size가 꽉 차 더 사용하지 못하는 것을 확인할 수 있고

 

 

실제로 에러도 발생하였습니다.

 

 

이제 VisualVm에서 Heap Dump로 확인해보겠습니다.

위와 같은 결과를 얻었습니다!

heap의 사이즈가 max 사이즈로 확인되고,

계속 추가했던 SomeObj를 2억개로 확인되고 있습니다.

 

그러므로 테스트로 실행했던 상황에서는

'Heap Size가 꽉 찼고, SomeObj 때문이구나. SomeObj를 해결할 수단을 강구해야겠다.'

라는 결론을 도출해낼 수 있습니다.

 

앞으로는 장애 상황에 대한 해결을 위해

명시적인 방법을 사용하여 판단과 해결책을 강구할 수 있도록 해야겠습니다.