[DB공통] DB 성능을 위한 모니터링 지표 10가지

 어플리케이션의 성능 문제를 마주하였을 때, 여러가지 요소들을 고려해야 한다. 어플리케이션 자체의 문제, 운영체제, 가상화(VM), 스토리지, 하드웨어 및 네트워크를 포함하여, 사용자와 DB 사이의 모든 가동 부분에 대해서 생각해 봐야 한다. 

 본 포스팅에서는 어플리케이션의 성능이 문제가 되었을 때, 적어도 DB에서 생기는 문제는 이 포스팅을 통해 모두 해결의 실마리를 찾고, DB외의 것들을 고려할 수 있는 단계로 넘어가는 것을 목표로 한다.

 

어떤식으로 데이터베이스를 모니터링 해야 하는가?

 데이터베이스 모니터링의 본질은 어느 특정한 날에 성능을 비교할, 과거 성능 통계 기록을 만들어 두는 것에 있다.

시간 경과에 따른 DB 성능을 모니터링하고, 장기적 관점에서 리소스 활용도를 요약하는 스냅샷 모음을 점진적으로 구축하여 이런 기록을 만들 수 있다.

 한 예로, DB 내에서 모니터링 표를 작성한 후, 주기적으로 단일 시점 통계를 수집하여 표를 채우는 프로세스를 자동화하는 방법이 있다. 이렇게 하면 DB의 성능이 느려질 경우, 직감이나 실험이 아닌 데이터에 입각한 결정을 내릴 수 있다.

 

모니터링 프로세스를 개발할 때의 유의사항

• 어떤 지표를 선택하든 그 지표의 기반은 트랜잭션 Workload(사용자 수, Batch 작업, 자동화 작업)이므로, 반드시 이를 기반으로 측정하여야 한다.
• 시간 범위가 길수록 정상적인 상태를 더 잘 파악할 수 있고, 변칙적인 상황이 발생하는 경우 더 쉽게 발견할 수 있으므로 모니터링은 가급적 빨리 시작하여 오랜 기간의 데이터를 축적하는 것이 중요하다.
• 트랜잭션 Volume이 급격하게 변하거나, 골치 아픈 문제가 발생하는 경우 더 자주 샘플링 해야 한다.
• 너무 지나친 오버헤드는 측정을 왜곡하므로, 결론에 영향을 미치지 않도록 수집 비용을 낮게 유지해야 한다.
• 시간, 트랜잭션 볼륨, 비즈니스 조건, 리소스 용량에 따라 변하는 임계값에 따라 적응형 알림을 사용한다. 이렇게 하면 거짓 양성 알림의 발생을 줄일 수 있다.
• 문제 해결을 엉뚱한 곳에서 시작하지 않도록, DB 구성 환경에서의 모든 수준에서 추세를 모니터링, 조사해야 한다.

---

DB 성능 지표

• 메모리 용량
  - 데이터 블록이 디스크에서 읽히면, 버퍼 캐시가 메모리에 데이터 블록의 사본을 저장
  - 새 데이터를 검색하기 위해 DB는 먼저 버퍼 캐시, 그 다음 디스크를 살펴 보는데, 이때 캐시(메모리에 저장됨)를 통해 데이터에 접근하는 것이 디스크를 통해 접근하는 것보다 훨씬 빠름.
  - 따라서 메모리의 현재 상태를 잘 관리해주어야 하므로, 메모리의 현재상태를 드러내는 매트릭스를 모니터링하는 것이 DB 성능 관리에 유익함.
  
  
• 캐시 히트율
  - DBMS가 찾으려는 데이터를 (버퍼)캐시에 저장된 Page들 사이에서 실제로 찾아낼 수 있는 빈도가 어느정도인지를 나타내는 수치.
  - 이 비율이 높을수록 시스템이 성능을 악화시키는 홉을 디스크에 만드는 케이스가 줄어듦.
  - 이 비율이 낮을수록 캐시 크기를 증가시켜야 할 때가 되었을 가능성이 높음.
  
  
• 페이지 기대 수명
  - 페이지가 메모리에 머문 초 단위 시간
  - 메모리 용량은 유한하므로 Page는 버퍼 캐시에 영원히 머무를 수 없으므로, 결국 최신 Page가 저장될 때마다 가장 오래된 데이터 Page는 지워지게 됨.
  - 이 수치가 높다는 것은, 그만큼 캐시 히트율이 높다는 얘기이므로(시스템이 버퍼캐시에서 데이터를 찾을 확률이 높다는 의미), 메모리가 효율적으로 운용되고 있다는 의미.
  - 이 수치가 낮다는 것은 Page가 메모리에 머무는 시간이 적다는 것이므로, 많이 사용되는 데이터가 메모리에 효율적으로 적재되지 못하거나, 메모리 자체 용량이 작다는 것을 의미.
  
  
• 초당 체크포인트 페이지 수
  - 체크포인트(CheckPoint) : 버퍼 캐시에서의 데이터가 변경되었으나, 데이터 파일(디스크에 위치)에 적용되지 않은 Dirty 버퍼를 데이터 파일에 Write하고, 이에 대한 정보를 컨트롤 파일과 데이터 파일 헤더에 기록하는 일련의 작업
  - 대부분의 경우 30보다 낮아야 하는데, 이 이상이라면 데이터파일에 아직 기록되지 않은 메모리상의 Dirty Page 수가 많다고 보는데, 이는 Write 연산이 많아서 디스크 I/O에 문제가 생길 확률을 높임을 의미한다.
  
  
• 리소스 사용량
  - DB에서 발생하는 모든 작업은 DB와 연관된 리소스 및 내부 객체에 영향을 미치는데, 이러한 리소스 및 객체에 집중한 DB 모니터링 매트릭스는 현재 및 잠재적인 성능 문제 파악에 도움을 줌.
  - 여기서 말하는 리소스는 주로 CPU 사용량이라고 볼 수 있음.
  - 리소스 사용량에 관한 매트릭스를 충분히 긴 기간동안 기록한다면, 워크로드의 주기적인 변화와 관련하여 용량 계획을 세울 수도 있음.
  
  
• 행(Row) 수
  - 마지막 SQL문의 영향을 받은 데이터 행(Row) 수 또는 가장 최근 시점에서 분석의 대상이 된 데이터 행 수를 말함.
  - 위 행 수를 이용하면 테이블에서 영향을 받은 데이터의 볼륨을 확인할 수 있는데, 만약 이 볼륨이 급작스럽게 늘어났거나 줄어들었다면, SQL문을 조사해 볼 필요가 있음.
  - 이후 애플리케이션을 변경할 방법을 찾을 수 있도록 시간 경과에 따른 시스템 변수와 스크립트를 사용하는 것이 바람직함.
  
  
• 데이터베이스 파일 I/O
  - 데이터 파일 또는 로그 파일에서 기록되고 읽히는 데이터의 양을 결정할 수 있음.
  - 이 매트릭스를 통해 파일 I/O 크기가 파일 크기에 적절한지 확인하는 데 유용.
  - 어느정도의 시간이 지나서 수치가 축적되면 추세 및 주기가 발생함을 확인할 수 있는데, 이를 통해 리소스 소비를 예측하는 데도 활용 가능.
  
  
• 잠금 및 블록(Locks and Blocks)
  - Locking 과 Blocking은 여러 개의 동시 트랜잭션이 동일한 객체에 액세스하지 못하도록 방지하는 역할.
  - 객체가 릴리스되고 다시 사용 가능하게 될 때까지 경쟁 프로세스를 보류.
    정상적인 경우라면, DMBS 자체적으로 릴리스하지만, 그렇지 않은 경우 릴리스가 방해되는 부분을 직접 제거해주어야
    함.
  
  
• 잠금 대기(Lock waits)
  - 일반적으로 이 수치는 Request 처리에 방해가 되기 때문에 되도록 0을 유지하는 것이 좋은데, 만일 이 수치가 늘어난다면 Load 시간이 늘어나는 것과 관련지을 수 있음.
  
  
• 차단(Bloking)
  - 잠금 대기 수치를 통해 DB 성능 저하가 생김을 확인했다면, Block 상태를 확인하고 Block을 일으키는 프로세스 또는 세션을 종료시켜야 한다.
  - 이 수치를 통해 SQL 튜닝 방향을 제시하여 어플리케이션의 쿼리를 Blocking이 발생하지 않도록 보다 효율적으로 만들어준다.
  
  
• 인덱스
  - 레코드가 테이블에 추가되고 삭제됨에 따라 인덱스 조각화 현상이 나타날 수 있는데, 이는 쿼리 옵티마이저의 비효율적인 쿼리 플랜을 선택하게끔 하여 성능 저하 문제가 발생하게 된다.
  - 인덱스 조각화 정도 등을 나타내는 인덱스 관련 수치를 통해, 인덱스를 Reorganization 또는 Rebuilding 하는 시기를 알아보고 인덱스를 효율적으로 개선시켜 DB의 성능 향상 효과를 볼 수 있다.

 

 

 

 

참고

https://blog.naver.com/PostView.naver?blogId=quest_kor&logNo=222188051970&parentCategoryNo=&categoryNo=&viewDate=&isShowPopularPosts=false&from=postView 

DB 성능 모니터링을 위한 10가지 지표