h2.Memory vs. Disk I/O
(1) I/O효율화 튜닝의 중요성
- Disk를 경유한 입출력 보다 메모리를 통한 입출력이 비교할 수 없을 정도로 빠르다.
- 물리적인 디스크 I/O가 필요할 때면 서버 프로세스는 I/O 서브시스템에 I/O Call을 발생시키고 잠시 대기하게 되므로 비용이 크다
- 오라클은 자주 액세스하는 블록들이 Cache에 더 오래 남아 있도록 LRU 알고리즘을 사용한다.
(2) Buffer Cache Hit Ratio
- 전체 읽은 블록 중에서 얼마큼을 메모리 버퍼 캐시에서 찾았는지를 나타내는 것이다.
- BCHR = (캐시에서 곧바로 찾은 블록 수 / 총 읽은 블록 수) * 100 = ( (논리적 블록 읽기 ? 물리적 블록 읽기) / 논리적 블록읽기) * 100 = (1 ? (물리적 블록 읽기) / (논리적 블록읽기) * 100)
- 논리적 블록읽기 = 총 읽은 블록 수
- 캐시에서 곧바로 찾은 블록 수 = 논리적 블록읽기 ? 물리적 블록 읽기
- BCHR은 온라인 트랜잭션을 주로 처리하는 시스템이라면 99% 달성을 목표로 삼아야 한다.
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 0.00 0.00 0 178 0 1
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 4 0.00 0.00 0 178 0 1
- Disk 항목이 '물리적 블록 읽기'에 해당
- '논리적 블록 읽기'는 Query와 Current 항목을 더해서 구하며, Direct Path Read 방식으로 읽은 블록이 없다.
- 이 두 값을 더한 것이 '총 읽은 블록 수'가 된다.
- 논리적인 블록 요청 횟수를 줄이고, 물리적으로 디스크에서 읽어야 할 블록 수를 줄이는 것이 I/O 효율화 튜닝의 핵심 원리{}{}이다.
- 같은 블록을 반복적으로 액세스하는 형태의 Appplication일 경우 논리적인 I/O요청이 비효율적으로 많이 발생하는데도 BCHR은 높게 나타날 수 있다. (BCHR의 한계점이다)
- 작은 테이블을 자주 액세스하면 모든 블록이 메모리에서 찾아지므로 BCHR는 높겠지만 블록을 찾는 과정에서 래치를 얻어야 하므로 큰 비용을 수반한다.
- 같은 블록을 여러 세션이 동시에 액세스함으로 인해 래치 경합과 버퍼 Lock경합 까지 ?생한다면 메모리 I/O 비용이 오히려 디스크 I/O 이상으로 커질 수 있다.
- BCHR가 100%라고 하더라도 논리적으로 읽어야 할 블록 수의 절대량이 많다면 반드시 SQL 튜닝을 실시해야 한다.
(3) 네트워크, 파일시스템 캐시가 I/O 효율에 미치는 영향
- 서버와 스토리지 간 NAS서버나 SAN을 통한 연결되는 Architecture를 사용
- 오라클은 CPU, RAM, 디스크를 일체형으로 개발한 MPP 방식의 어플라이언스 제품들을 이용하여 네트워크 속도를 줄일려고 함.
- RAC 서버에서 INSTANCE 끼리 네트워크를 통해 캐시된 블록들을 서로 공유하므로 메모리 I/O성능에도 네트워크 속도가 영향을 미침.
- I/O 성능에 관한 가장 확실하고 근본적인 해결책은 논리적인 블록 요청 횟수를 최소화 하는 것{}{}이다.
문서에 대하여
- 최초작성자 : 미녀씨
- 최초작성일 : 2010년 01월 15일
- 이 문서는 오라클클럽 코어 오라클 데이터베이스 스터디 모임에서 작성하였습니다.
- {*}이 문서의 내용은 (주)비투엔컬설팅에서 출간한 '오라클 성능 고도화 원리와 해법I'를 참고하였습니다.*