[Oracle 구조] 3. 캐시와 공유 메모리

📌 3장에서는 SQL문을 고속으로 처리하는 오라클의 데이터 캐시 기능(버퍼 캐시)와 오라클의 

      프로세스가 캐시를 공유하기 위해 사용하는 특수한 메모리 기능(공유 메모리)에 관해 살펴봅니다. 

 

3.1 | 어째서 캐시가 필요한 것인가?

· 디스크가 동작하는 것은 매우 느리고 I/O 1회에 10~20밀리초 정도 걸리기 때문에 오라클은 '캐시'라고 불리는 기술을 사용해 가능한 한 디스크에서 처리하지 않고, 메모리에서 처리하는 구조를 갖고 있음

· 캐시는 가장 간단한 튜닝 항목이자 잘 알려진 기능 중 하나이며, 캐시의 동작을 잘 이해하면 데이터베이스 성능을 올려줄 수 있음

 

 

3.2 | 그래서 캐시란 대체 무엇인가? 

· 캐시란 빈번하게 사용하는 데이터를 매번 디스크에서 꺼내오지 않고 캐시라고 불리는 메모리에 둠으로써 빠르게 사용할 수 있도록 하는 것

· 디스크의 데이터를 처리해야 할 때, 이 메모리(캐시)에 같은 데이터가 존재하면 디스크에서 읽을 필요 없이 CPU에게 데이터를 직접 건네줄 수 있음

· 원하는 데이터가 버퍼 캐시에 존재할 때와 존재하지 않을 때 '처리속도'의 차이가 발생

- 캐시에 히트할 경우 : 처리 속도가 느린 디스크를 사용할 필요가 없어 SQL문의 처리 속도가 빨라짐

- 캐시에 히트되지 않을 경우 : 처리 속도가 느린 디스크에서 읽어올 수 밖에 없어 SQL 처리가 느려짐

· 캐시를 '작업장'이나 '작업대'에 비유할 수 있음. 자주 사용하는 도구나 책을 서랍이나 책장에 두는 것과 유사

 

 

3.3 | 데이터는 블록 단위로 관리 

· 오라클은 '블록'이라고 하는 단위로 데이터를 관리함. I/O의 단위와 버퍼 캐시도 블록 단위로 관리

· 한 개의 블록에는 여러 건의 데이터가 보관돼 있으므로 한 건만을 디스크에서 읽어오려고 해도 필요한 데이터를 포함하고 있는 블록 전체가 캐시에 보관됨 

 

 

3.4 | 캐시를 사용해서 인덱스 검색을 효율적으로 

· 테이블뿐만 아니라 인덱스도 블록으로 구성되어 있음.

· 계층 구조를 가진 인덱스를 사용해서 데이터를 한 건 가져오는 경우, 캐시에 데이터가 없을 때 걸리는 처리 시간은 41.2 밀리초이고, 캐시에 데이터가 있을 때 걸리는 처리 시간은 1.2밀리초로 캐시의 유무 차이가 매우 큼

 

 

3.5 | 프로세스는 캐시를 공유

· OS는 '공유 메모리'라는 특수한 메모리 기능을 제공함. 공유 메모리를 사용하면 자신의 메모리 영역에 기록했던 데이터를 다른 프로세스에서도 볼 수 있음.

· 다수의 프로세스로 구성된 DBMS에게 공유 메모리는 매우 편리한 도구이기도 하며, 필수 기능

· 각 프로세스에게는 마치 자신의 메모리인 것처럼 보이지만, 실제로는 실제 메모리는 한개이며 모든 프로세스가 같은 메모리 영역에 접근하고 있는 것. 오라클에서는 이런 공유 메모리를 'SGA(System Global Area)', 공유하지 않는 메모리의 일부를 'PGA(Program Global Area)'라고 부름

- SGA(System Global Area) : 프로세스가 공유해야 하는 데이터를 보관하는 메모리

- PGA(Program Global Area) : 서버 프로세스마다 존재하는 메모리

 

 

3.6 | 공유 메모리에 필요한 설정

· 버퍼 캐시는 성능과 직결되기 때문에 크기를 정할 때 신중해야 함.

· 오라클의 설정 파일인 spfileXXXX.ora는 버퍼 캐시의 크기를 결정하는 'DB CACHE SIZE' 파라미터가 존재

[ 버퍼 캐시 크기 설정법 ]

1. 자동 공유 메모리 관리 : SGA만 크기 설정해 놓으면 나머지는 오라클이 알아서 관리

2. 자동 PGA 메모리 관리 : PGA 내의 영역을 자동으로 관리

3. 자동 메모리 관리 : SGA와 PGA간의 비율도 자동으로 조정

 

 

3.7 | 공유 메모리는 어떤 식으로 보이는가?

· 공유 메모리는 특수한 메모리이므로, 모든 프로세스마다 공유 메모리를 포함하여 보여주는 OS도 있고, 전혀 포함하지 않고 보여주는 OS도 있음. 

· ps 명령어로 보았을 때, 가상 메모리의 크기(VSZ)는 각 프로세스가 일정 크기의 메모리를 사용하고 있는 것으로 보이나, 실제 대량의 메모리를 사용하고 있는 것은 아니며, 공유 메모리의 사용량을 중복해서 표기하기 때문에 나타나는 현상임.

 

 

3.8 | 버퍼 캐시를 정리하는 LRU 알고리즘 

· 버퍼 캐시는 자주 사용하는 데이터를 더 빠르게 가져오기 위해 존재. 또한, 버퍼 캐시의 크기는 한정되어 있으므로 관리하고 정리해야 할 필요성이 있음. 이를 위해 캐시에 LRU(Least Recently Used)알고리즘을 사용

· LRU(Least Recently Used) : 최근에 사용하지 않은 데이터부터 캐시 아웃(버린다)하는 알고리즘

· 오라클은 큰 테이블이라고 판단되면 버퍼 캐시로 블록(데이터)을 적재하지 않으며, 풀스캔했을 때의 데이터는 일반적으로 버퍼 캐시에 적재되지 않음

 

 

3.9 | 오라클뿐만이 아닌 OS나 스토리지에 대해서도 생각하자

·  OS와 스토리지 관련된 아키텍처와 동작까지 시야를 넓혀보면, 최근 주목받는 것은 스토리지의 캐시임. 스토리지에서 데이터를 읽어오는 것은 당연히 빨라지지만,  스토리지 캐시에 데이터를 기록하면 OS의 관점에서의 I/O는 종료할 수 있기 때문에 더더욱 유용

 

3.9.1 OS의 버퍼 캐시와 가상 메모리의 차이

· OS에는 버퍼 캐시와 가상메모리라는 두 가지 기능이 존재. 오라클의 버퍼 캐시와 비슷한 기능을 가지고 있음

- 버퍼 캐시 : 디스크에 빠르게 접근하기 위해 메모리의 일정 부분을 할당하여 사용

- 가상 메모리 :  속도가 느려지더라도 사용할 수 있는 메모리의 크기를 늘리기 위해서 디스크를 사용. 최근에 사용하지 않은 데이터를 프로세스 몰래 디스크에 보관해두어 이를 통해 메모리가 실제 메모리보다 많은 것처럼 보여짐

 

· 아래 동작을 페이징(paging)이라고 하며, 이는 물리 메모리와 디스크 사이에서 블록(페이지)를 주고 받는 것

- 페이지 아웃(page out) : 물리 메모리의 페이지를 디스크에 기록하는 것

(ex. 데이터를 사용하지 않아 디스크로 옮김)

- 페이지 인(page in) : 디스크의 페이지를 물리 메모리로 읽어오는 것

(ex. 프로세스 요청으로 디스크에서 읽어 옴)

 

 

3.10 | 요약 

· 오라클을 사용할 때에는 아키텍처나 동작의 이미지를 통해 '캐시의 데이터를 사용하기 위해서는 어떻게 하는 것이 가장 좋을까?'를 고민하며 설계와 튜닝을 진행 

· OS와 스토리지의 캐시나 동작까지 고려하면 더 좋은 설계나 해결책을 찾을 수 있음