실험 개요
실험 제목 : exp003_DB CPU 한계점 파악 실험
실험 코드 : test-pyramid-20230224-002
관련 실험 : test-pyramid-20230224-001
실험 상황 : 부하 테스트 툴 nGrinder을 활용한 서버 부하 테스트 진행중
실험 목적 : partial selection 코드를 적용한 API에 15분 간 장기간 부하주는 상황에서의 성능 관측
결론
- 에이전트 2개로 Vuser 40으로 설정하여 러닝타임을 15분으로 테스트를 진행함
- 테스트 시작 3분 이후 DB CPU 사용률이 약 98% 수준에 도달했다
- DB CPU 한계치에 도달한 이후에도 12분동안 지속된 것을 통해 최대 CPU 사용 환경에서의 DB의 지속 가능시간이 약 12분임을 알게됨
테스트 앞서
maxQueryExecution Time 설정하기
이번 테스트에 앞서 long-running query를 출력해주는 옵션을 적용시켜주고 시작하겠다. Orm config 설정해주는 부분에 maxQueryExecutionTime
옵션을 설정해주면 된다.
return {
type: 'postgres',
host: configService.get('RDS_HOST'),
port: configService.get('RDS_PORT'),
username: configService.get('RDS_USERNAME'),
password: configService.get('RDS_PASSWORD'),
database: configService.get('RDS_DATABASE_NAME'),
entities: [__dirname + '/../**/*.entity{.ts,.js}'],
synchronize: true,
logging: ['log'],
maxQueryExecutionTime: 1000, // log if one query run over 1000ms time
extra: {
statement_timeout: 1500
}
};
위의 경우 1000ms 내 마치지 않는 쿼리를 로깅해주고, 1500ms이 넘어가면 timeout으로 쿼리를 취소시켜준다.
만약 서비스의 평균 응답 속도를 알고 있다면, 이보다 살짝 오버되는 쿼리들은 미리 취소시켜서 전체 서비스의 장애로 문제가 확장되는 것을 방지할 수 있다고 한다. (참조 : https://jojoldu.tistory.com/631) 참고로 공식 문서에서는 1000ms로 되어있다.
테스트 계획
테스트 결과
nGrinder 리포트
테스트 시간은 총 15:00이다. 테스트 진행 시작 이후 13:30부터 급격히 하락하더니 TSP가 0으로 수렴.
13:46부터는 요청 처리수가 0으로 급감했다. 이 상태는 14:44까지, 약 1분간 지속되다 결국 DB가 정지된 것으로 추정된다.
한 가지 의문이 드는 부분은 DB가 왜 테스트 시간 15:00보다 16초 이른 14:44에 종료되었냐는 점이다. 테스트 시간을 15분으로 설정해도 Vuser 설정에 따라 소프트웨어 내에서 동적으로 테스트 시간을 바꾸는 것일까, 아니면 1분간 DB의 퍼포먼스가 생기지 않자 자동으로 중지된 것일까.
Latency도 도중 가끔씩 튀는 것들이 있긴 하지만 전체적으로는 안적정인 흐름을 이어갔다.
Application Server
EC2의 모니터링 상황인데, CPU 사용률은 41.7까지 상승했다.
DB
반면 DB의 CPU 사용률은 약 100% 수준까지 상승했다. 프로젝트 시작 후 최대치에 근접한 경우는 처음이다. 최대치라는 수치는 이 어플리케이션의 한계의 기준에 대한 실마리를 줄 수 있는 지표라는 점에서 유의미한 성과다.
DB의 CPU 사용률을 상세하게 살펴보면 22:09부터 22:11 사이, 즉 2분 내 CPU 사용률 약 98%까지 급격히 도달한 점이 특징이다. 100%처럼 보이지만 97 - 98% 사이를 오가고 있다.
흥미로운 점은 22:11분 경 DB CPU 사용율이 최대치에 도달한 뒤로 22:23분까지 그 상태를 유지했다는 점이다. 즉, 약 12분간 CPU 사용률을 최대치까지 사용하다 결국 DB가 중지되었다.
주요 데이터
- TSP : 140
- MTT(Mean Test Time) : 263
- Web server CPU % : 41.7%
- DB CPU % : 98%
인사이트
- 에이전트 2개로 Vuser 40으로 설정하여 러닝타임을 15분으로 테스트를 진행함
- 테스트 시작 3분 이후 DB CPU 사용률이 약 98% 수준에 도달했다
- DB CPU 한계치에 도달한 이후에도 12분동안 지속된 것을 통해 최대 CPU 사용 환경에서의 DB의 지속 가능시간이 약 12분임을 알게됨
레퍼런스
'Log > Experiment' 카테고리의 다른 글
exp006_Redis 적용 로직 VUser 변동에 따른 성능 비교 (0) | 2023.03.01 |
---|---|
exp005_Redis 적용 후 조회 성능 변화 관찰 실험 (0) | 2023.02.27 |
exp004_동일한 로직을 다른 시간대에 테스트하여 성능 차이 비교 (0) | 2023.02.27 |
exp002_TypeOrm_partial Selection 사용 여부에 따른 성능 변화 관찰 (0) | 2023.02.24 |
exp001_TypeOrm_관계 참조 여부에 따른 쿼리 성능 비교 실험 (0) | 2023.02.24 |
댓글