Section4. Buffer_Cache Hit_Ratio의 이해 및 문제점

[출처: 오라클 성능 분석과 인스턴스 튜닝 핵심 가이드]

Buffer Cache Hit Ratio

• 시스템이 얼마나 Disk I/O를 줄이고 Buffer Cache를 잘 활용하고 있는지를 나타내는 지표
• Hit Ratio = (1 - (Physical reads / Logical Reads ) ) * 100 
  • Logical Reads: Buffer Cache Block 액세스 수
  • Pyhsical Reads: Disk Block 액세스 수 

 

Buffer Cache Hit Ratio 통계 함정 (1)

• Buffer Cache Hit Ratio 99% 이면 전반적인 SQL 수행속도가 양호한 것일까?
  • 100,000의 1%   VS    1,000,000,000의 1%
    • ->십만의 1%는 천, 그러나 십억의 1%는 천만. 이 천만이 physical Reads를 하게 되는 것임.
      • physical Reads는 절대량에 영향을 받기 때문에 십억건 데이터의 1%인 천만건은 엄청난 burden이 됨.
    • 수백, 수천 개의 SQL 중 단 1%의 SQL들의 호출빈도가 전체 SQL 호출 빈도에 대부분을 차지하게 된다면?
    • 만약 Applicatoin 전체적으로 SQL들이 Block을 많이 Access 해야 되는, 잘 튜닝 되어 있지않은 SQL 이라면?
• Access Block 수는 작지만 호출 빈도가 매우 높은 경우 전체 Logical Reads는 "호출 횟수 x Acces Block 수"가 되어 크게 증가하게 됨
  • "호출"이란 여러 client가 특정 block 정보를 자주 액세스하면 호출 빈도가 높다고 표현 함.
  • 예를들면 10개 block을 1초에 100회 Access 하면 1000 block을 access 한 것과 동일한 burden을 가짐. 이러한 Access를 1시간 하면 [10 blocks * 3600 * 100 = 36000 ]. 
  • 위의 예시처럼 된다면 Logical Reads의 숫자가 확 높아지게 됨.
• 호출 빈도가 높으면서 Access Block 수는 많은 SQL들이 Buffer Cache를 지속적으로 점유하게 되면 Logical Reads는 크게 증가하게 됨.
• 이들을 제외한 다른 많은 SQL들은 Buffer Cache 공간을 차지 할 기회가 상대적으로 적어 디스크 Access를 많이 하게 되나, 워낙 호출 빈도 수가 높은 SQL들의 Logical Reads 수치가 높아 Buffer Cache Hit Ratio 가 높게 나오는 현상 발생 
•  현업의 경우 대부분 Hit Ratio가 99% 여서, 이 수치만 보고 튜닝을 안하면 안 됨(통계함정!)

 

Buffer Cache Hit Ratio 통계 함정 (2)

• 저녁/새벽에 수행되는 Batch 프로그램은 Buffer Cache Hit Ratio를 떨어뜨리지만, Batch 수행 시 저하되는 Hit Ratio 는 워낙 대용량 데이터를 처리하면서 발생하므로 자연스러운 현상 일 수 있음.

 

Buffer Cache Hit Ratio 통계 함정 (3)

• Hit Ratio와 같은 성능 통계 정보는 불균일한 Load가 발생할 경우 정확한 문제 인식을 제공하지 못할 가능성이 높음.
• ↓
• 퍼센트가 아닌 절대 일량 수치 (메모리 Access량, 디스크 Access 량)을 기준으로 성능 평가 필요
• ↓
• Buffer Cache Hit Ratio 외에 Load Profile + Wait Event를 결합한 분석 필요