본문 바로가기
Log/Experiment

exp003_DB CPU 한계점 파악 실험

by RIEM 2023. 2. 27.

실험 개요

실험 제목 : 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로 되어있다.

테스트 계획

Screen Shot 2023-02-27 at 12 16 09 AM

테스트 결과

nGrinder 리포트

Screen Shot 2023-02-26 at 11 50 49 PM|1000Screen Shot 2023-02-26 at 11 51 22 PM|1000

테스트 시간은 총 15:00이다. 테스트 진행 시작 이후 13:30부터 급격히 하락하더니 TSP가 0으로 수렴.

13:46부터는 요청 처리수가 0으로 급감했다. 이 상태는 14:44까지, 약 1분간 지속되다 결국 DB가 정지된 것으로 추정된다.
한 가지 의문이 드는 부분은 DB가 왜 테스트 시간 15:00보다 16초 이른 14:44에 종료되었냐는 점이다. 테스트 시간을 15분으로 설정해도 Vuser 설정에 따라 소프트웨어 내에서 동적으로 테스트 시간을 바꾸는 것일까, 아니면 1분간 DB의 퍼포먼스가 생기지 않자 자동으로 중지된 것일까.

Screen Shot 2023-02-26 at 11 52 40 PM|1000


Latency도 도중 가끔씩 튀는 것들이 있긴 하지만 전체적으로는 안적정인 흐름을 이어갔다.

Application Server

Screen Shot 2023-02-26 at 11 59 03 PM|1000


EC2의 모니터링 상황인데, CPU 사용률은 41.7까지 상승했다.

DB

Screen Shot 2023-02-27 at 12 00 00 AM|1000


반면 DB의 CPU 사용률은 약 100% 수준까지 상승했다. 프로젝트 시작 후 최대치에 근접한 경우는 처음이다. 최대치라는 수치는 이 어플리케이션의 한계의 기준에 대한 실마리를 줄 수 있는 지표라는 점에서 유의미한 성과다.

Screen Shot 2023-02-27 at 12 02 14 AM


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분임을 알게됨

레퍼런스

댓글