• 동시접속률을 증가시키기 위해 여러 개의 쓰레드가 하나의 캐시를 동시에 사용할 수 있다 : 물론 하나의 쓰레드가 캐시를 수정하는 경우 다른 쓰레드들은 수정이 완료될 때까지 잠시 기다린다.

• 키 캐시 블럭의 교체를 위해 기본적인 큐 방식 이외에도 추가적으로 매우 복잡한 알고리즘을 제공한다 : 이른바 ‘중간 삽입 전략(Midpoint Insertion Strategy)’이라고 하는 방식을 제공하는데 이는 사용률에 따라 구분하는 방식을 말한다. 이 방식이 적용될 경우 키 캐시 블럭의 교체를 위한 후보를 구분할 때 사용 빈도에 따라 핫리스트(Hot List)와 웜리스트(Warm List)로 구분한다.

MyISAM 키 캐시의 설정

키 캐시가 어떻게 동작하는지 알아봤다. 이제는 키 캐시를 어떻게 설정하고 동작방식을 제어하는지 알아보자. 다중 키 캐시를 구성할 것인지와 만약 구성한다면 몇 개 정도를 구성할지 결정한다. 몇 개를 설정할지가 중요한 것이 아니라 각 키 캐시가 성능에 어떻게 영향을 미칠지 이해하는 것이 각 키 캐시를 설정하고 모니터링하며 튜닝하는 것만큼 중요하다. 각 키 캐시를 위해 적절한 값을 설정한다. 키 캐시를 만들 때마다 다음과 같은 몇 가지 항목에 대해 결정해야 한다.

• 키 캐시 버퍼의 메모리 크기를 정한다 : key_cache_block_size 파라미터를 통해 각 키 캐시 버퍼가 얼마나 많은 메모리를 사용할지 설정한다. 1024바이트가 기본 값이며 이 값은 대부분의 애플리케이션에 적합하다. 현재 MySQL에서는 이 값의 변화가 큰 의미를 가지지 않으나 앞으로 이 파라미터가 좀 더 중요한 역할을 하도록 변경될 예정이다.

• 키 캐시에 메모리를 할당한다 : 가장 중요한 항목이다. key_buffer_size 변수를 너무 작게 설정하는 것은 키 캐시가 주는 이득을 제대로 활용하지 못하는 것이며 너무 크게 주는 것은 소중한 메모리 공간을 낭비하는 것이 된다. 각자의 환경이 모두 다르기 때문에 이것이 가장 좋다고 추천할 수 있는 값은 존재하지 않지만 일단 모든 키 캐시의 메모리 사용량이 전체 메모리의 5~10%가 되도록 설정하는 것이 바람직한 튜닝의 시작이다. 먼저 이 정도의 값을 설정한 후 모니터링 결과에 따라 값을 올리도록 하자.

• 중간 삽입 전략을 사용할지 결정하자 : 이 방식을 사용하지 않으려면 key_cache_ division_limit를 100으로 설정하면 된다. 이 파라미터를 30으로 설정하면 웜리스트를 위해 30% 이상의 공간을 배정하지 않게 된다.

이제 인덱스와 원하는 캐시를 연결시켜 준다. CACHE INDEX문을 통해 키 캐시와 그 키 캐시를 사용할 인덱스를 지정해 줄 수 있다. 그 다음 키 캐시를 미리 로딩할지를 결정한다. MySQL은 키 캐시가 해당 레코드를 요청할 때 바로 로딩되거나 미리 로딩할지를 선택할 수 있다. 만일 미리 로딩하기를 원한다면 LOAD INDEX문을 통해 로딩 작업을 수행할 수 있다. LOAD INDEX문을 통해 로딩할 메모리의 양은 preload_buffer_size 파라미터를 통해 설정할 수 있다.

이렇게 설정한 후 키 캐시를 모니터링한다. 키 캐시의 성능을 모니터링하는 방법은 여러 가지가 있지만 MySQL Administrator를 사용하는 것이 가장 효율적이다. 키 캐시의 정보를 삭제하는 방법은 MySQL 서버를 재시작하거나 key_buffer_size를 변경하는 것이다.

MyISAM 키 캐시의 모니터링과 튜닝

키 캐시의 설정이 끝났다면 이제는 키 캐시의 모니터링을 위해 MySQL Administrator에 몇 가지 그래프를 추가하자. <화면 1>은 키 캐시 모니터링을 위해 MyISAM Activity라는 페이지를 만들어 필요한 그래프들을 추가해 놓은 상태이다.

키 캐시 사용량
현재 얼마나 많은 양의 키 캐시가 사용되고 있는지 그래프로서 표현하려면 계속적으로 변하는 값인 key_block_used와 각 block의 크기인 key_block_size를 곱한 값을 최대 키 캐시 사이즈인 key_buffer_size 와 비교해 알 수 있다. 그래프를 추가한 후 value fomula에 ‘[Key_ blocks_used]×[key_cache_block_size]’를 사용하고 Max fomular에 key_buffer_size를 입력한 후 바 그래프(bar graph)로 설정하면 사용량을 쉽게 알 수 있다. 이 그래프를 모니터링함으로써 기본적으로 키 캐시 사이즈가 적절히 설정되었는지를 확인할 수 있다. 만약 순식간에 그래프가 최고치에 도달한다면 키 캐시에 좀 더 많은 메모리를 할당할 필요가 있으며 반대로 지속적으로 저조한 사용량을 보인다면 값을 줄일 필요가 있다. 10분 정도의 모니터링 결과로 값을 결정하는 것은 바람직하지 않으며 최소한 피크 타임과 일반적인 사용 시에 각각 1시간 정도씩 모니터링한 후 적절한 값을 설정하는 것이 좋다.

키 캐시 읽기 적중률
MySQL이 디스크가 아닌 키 캐시에서 얼마나 많이 읽어오는지를 파악하려면 다음의 공식을 통해 그래프를 만들 수 있다.

계산식 = 100-(^[key_read]/^[key_read_request])×100

그렇다면 이 그래프를 어떻게 해석할 수 있을까? 만약 지속적으로 90% 이상의 적중률을 보인다면 키 캐시가 효율적으로 설정된 것이며 적중률이 지나치게 낮다면 키 캐시 메모리를 증가시킬 필요가 있다. 하지만 데이터베이스가 엄청나게 크거나 여러 데이터를 골고루 많이 읽는 데이터베이스라면 아무리 많은 양의 키 캐시를 설정해도 이와 같은 결과를 얻을 수밖에 없다. 그리고 적중률이 99~100%를 기록한다면 그 역시 너무 많은 메모리가 키 캐시에 할당된 것이다. 이런 경우에는 값이 떨어지기 시작하는 시점까지 지속적으로 키 캐시 메모리 할당량을 줄여야 한다.

<화면 1> MySAM 모니터링을 위해 구성해 놓은 MySQL Administrator

키 캐시 쓰기 적중률
이 그래프는 키 캐시 쓰기 요청과 실제로 디스크에 쓰이는 키 블럭간의 상관관계를 볼 수 있다. 계산식은 다음과 같다.

계산식 = 100-(^[key_writes]/^[key_write_requests[]×100

일반적으로 키 캐시 쓰기 적중률은 읽기 적중률보다 상당히 낮은 값을 나타내는 것이 정상이다. 하지만 대용량 데이터 입력이나 큰 인덱스를 생성하는 경우 순간적으로 값이 높아질 수 있으니 주의해야 한다.

키 캐시 읽기 I/O
<화면 1>의 키 캐시 I/O 중 위에 있는 두 그래프는 key_read_request와 key_read의 횟수를 보여주는 그래프이다. 두 가지 그래프를 비교함으로써 MySQL이 얼마나 많은 정보를 디스크가 아닌 키 캐시에서 읽어 오는지를 알 수 있다.

키 캐시 쓰기 I/O
<화면 1>의 키 캐시 I/O 중 밑에 있는 두 그래프를 통해 키 캐시가 얼마나 많이 쓰이고 있는지 알 수 있다. 성공적인 키 캐시 쓰기 요청(key_write_request)과 디스크에 쓰여진 횟수(key_writes)를 비교하게 된다.

MyISAM 기타 메모리 관련 파라미터 정리

MyISAM에는 키 캐시 외에도 각각의 작업별로 영향을 미치는 여러 가지 메모리 관련 파라미터들이 있다. <표 1>은 각종 파라미터들을 전체 스토리지 엔진에 영향을 미치는 파라미터와 각 쓰레드에만 영향을 미치는 파라미터로 나눠 정리한 것이다.

InnoDB 스토리지 엔진 튜닝

MySQL 3.x 버전에서 트랜잭션을 지원하기 위해 도입된 InnoDB 스토리지 엔진은 처음에는 MyISAM에 비해 지나치게 느린 성능 등을 이유로 많이 사용되지 않았다. 하지만 성능이 지속적으로 향상되고 트랜잭션 지원에 대한 사용자들의 요구사항이 많아지면서 현재는 MyISAM과 거의 대등한 위치에 올라선 스토리지 엔진이다. InnoDB 스토리지 엔진의 특징이라면 무엇보다도 ACID를 완벽히 만족하는 트랜잭션의 지원과 로우 레벨 락킹이다. MySQL이 점차 다양한 기업 환경에 사용되고 주요 업무에도 도입되면서 InnoDB는 점차 MySQL의 주요 스토리지 엔진으로 자리 잡을 것으로 예상되며 MySQL AB에서도 InnoDB에 성능개선에 많은 노력을 기울여왔다. 그 결과가 이번에 발표되는 MySQL 5.0 버전이며, MySQL 5.0.7 베타 버전을 기준으로 행해진 내부 벤치마크 테스트에서는 Select에서도 MyISAM보다 30% 이상 뛰어난 성능을 보여 MySQL AB의 내부에서도 큰 반향을 일으켰다. 그럼 앞으로 MySQL을 대표하는 스토리지 엔진이 될 InnoDB의 튜닝에 대해 알아보자

InnoDB 버퍼 풀의 설정

MyISAM의 튜닝에서 가장 큰 부분을 차지하는 것이 키 캐시라면 InnoDB에서 가장 큰 부분을 차지하는 것은 바로 버퍼 풀이다. 버퍼 풀의 크기를 조절하는 파라미터는 innodb_buffer_pool_size로 일반적으로 전체 시스템 메모리의 50~80% 정도를 설정한다. 다음은 버퍼 풀의 크기를 결정하기 전에 고려할 사항이다.

• 서버의 용도 : 만일 서버를 MySQL 전용 서버로 사용한다면 마음 놓고 버퍼 풀 크기를 올릴 수 있다. 하지만 서버에서 웹 서버나 애플리케이션 서버를 함께 운영한다면 꼭 필요한 만큼만 설정하도록 주의를 기울여야 한다.

• 사용 가능한 시스템 메모리 : MySQL 전용 서버라 할지라도 전체 물리적 메모리의 80%나 그 이상을 설정하는 것은 전반적인 시스템 성능에 큰 무리를 준다.

• 데이터베이스의 사용 유형 : 쓰기 중심의 데이터베이스 서버와 읽기 중심의 데이터베이스 서버는 버퍼 풀에 대한 요구사항이 크게 달라진다. 이것이 바로 버퍼 풀의 사용현황을 꾸준히 모니터링해야 하는 이유이다.

• 다중 스토리지 엔진의 사용 : MyISAM의 키 캐시와 InnoDB 버퍼 풀은 서로에게는 전혀 도움이 되지 않고 오히려 한정된 메모리를 가지고 경쟁하는 관계이다. 그러므로 각 스토리지 엔진 별로 사용 빈도나 용도를 잘 따져서 설정해야 한다.

이런 사항들을 고려해 버퍼 풀 크기를 결정했다면 이제는 버퍼 풀과 관련된 몇 가지 파라미터들을 조정해야 한다. 버퍼 풀은 InnoDB의 인덱스와 데이터 정보를 캐싱하는 메인 메모리 캐시이기 때문에 다음 두 가지 사항은 매우 중요한 문제이다

• 변화된 캐시 페이지는 정기적으로 디스크에 기록해야 한다. 그렇지 않으면 서버 다운이 예상치 못하게 발생했을 때 캐싱된 데이터는 유실된다.

• 버퍼 풀에는 새로운 데이터 또는 인덱스 그리고 사용자가 직접 데이터베이스를 조작할 경우를 위한 공간을 반드시 남겨 둬야 한다.

Innodb_max_dirty_page_pct는 이런 두 가지 요구사항을 충족시키는 것을 도와주는 파라미터이다. 0부터 100까지 설정할 수 있으며 설정한 수치에 따라 InnoDB 쓰레드가 디스크와 싱크하도록 지시한다. 예를 들어 이 파라미터를 80으로 설정하면 InnoDB는 전체 버퍼 풀의 80% 이상이 수정되었거나 필요 없는 캐시 페이지 즉 더티 페이지를 가질 수 없도록 한다.

<화면 2> InnoDB 모니터링을 위해 구성해 놓은 MySQL Administrator

윈도우에서의 버퍼 풀 크기 한계를 뛰어넘기 위한 파라미터 역시 제공하는데 이것이 MS에서 최근에 발표한 AWE(Address Windowing Extensions)라는 메모리 확장 기술을이다. 이는 기존 윈도우 시스템의 메모리 한계인 4GB 이상을 관리자가 사용할 수 있도록 해 주는 기술로써 innodb_buffer_pool_awe_mem_mb 라는 파라미터이다. 이 파라미터를 통해 64GB까지의 메모리를 버퍼 풀로 사용할 수 있다. 그리고 버퍼 풀 이외에 메모리가 필요한 작업들을 위해 설정하는 파라미터로서 innodb_additinoal_mem_pool_size라는 파라미터가 있는데 대부분의 경우는 기본 값으로 설정해도 무방하다.

InnoDB 버퍼 풀의 모니터링과 튜닝

앞에서 MyISAM 스토리지 엔진에서 한 것과 같이 InnoDB 버퍼 풀을 위해 MySQL Administrator에 커스텀 그래프들을 생성해 모니터링하고 이를 바탕으로 튜닝을 하자. <화면 2>는 버퍼 풀을 모니터링하기 위해 새로운 페이지를 구성한 것이다.

버퍼 풀 사용량
전체 버퍼 풀 크기인 innodb_buffer_pool_pages_total 중에서 현재 사용중인 버퍼 풀 크기인 innodb_buffer_pool_pages_data로 전체 버퍼 풀 사용량을 알 수 있다. 시작하자마자 차지하는 용량은 InnoDB가 내부적인 용도로 사용중인 것이다.

버퍼 풀 내의 더티 페이지 사용량
전체 버퍼 풀 크기인 innodb_buffer_pool_pages_total 중에서 현재 사용중인 더티 페이지 크기인 innodb_ _pool_pages_dirty로 전체 버퍼 풀 중 더티 페이지가 차지하는 용량을 알 수 있다.

버퍼 풀 적중률
버퍼 풀이 용도에 맞게 효율적으로 설정되었는지 판단하는 가장 중요한 그래프이다. 그래프의 계산 공식은 다음과 같다.

계산공식 = 100-(100×(^[innodb_pages_read]/^[innodb_buffer_pool_read_ requests]))

이 계산 공식은 전체 버퍼 풀 읽기 요청 중 실제로 디스크에서 읽지 않고 버퍼 풀에서 읽은 횟수를 계산하는 것이다. 이 수치가 높다는 것은 버퍼 풀이 적절히 구성되어 동작중이라는 것이고 수치가 낮은 것은 버퍼 풀에서 실제로 자주 필요로 하는 정보를 찾을 수 없다는 것이다.

버퍼 풀 읽기 요청
이 그래프는 시시각각 변하는 버퍼 풀 읽기 요청을 모니터링하기 위해 쓰인다. 언제 어떤 작업을 수행하기 위해 갑자기 버퍼 풀 읽기 요청이 증가하는지를 파악하는데 도움을 준다.

버퍼 풀의 연속적인 데이터 미리 읽기 활동 측정
InnoDB는 복잡한 알고리즘으로 구현되어 있으며 어떠한 프로그램이 많은 양의 연속적인 데이터 읽기 작업으로 보통 전체 테이블 스캔되는 경우 등이 발생할지를 미리 판단한다. Innodb_buffer_pool_ read_ahead_seq의 상태를 지속적으로 모니터링함으로써 파악할 수 있으며 계속해서 상승하는 것은 InnoDB가 더 많은 테이블 스캔을 하고 있다는 의미이다.

버퍼 풀의 랜덤한 미리 읽기 활동 측정
InnoDB의 미리 읽기 알고리즘(read-ahead algorithm)은 연속적인 읽기뿐만 아니라 비연속적인 읽기가 대량으로 발생하는 것도 미리 예측해 작업을 한다. 이는 innodb_buffer_pool_read_ahead_rnd의 상태를 모니터링함으로써 파악할 수 있다.

버퍼 풀에 대한 쓰기 요청
버퍼 풀이 얼마나 자주 변경되는지 파악하려면 계속적으로 변하는 값인 innodb_buffer_pool_write_request의 상태를 추적하면 된다.

플러시된 버퍼 풀 페이지
앞에서 언급했듯이 MySQL은 정기적으로 버퍼 풀에 있는 페이지를 디스크로 싱크하는 작업을 한다. 이는 데이터의 순간적인 손실을 막기 위한 작업이다. Innodb_buffer_pool_pages_flushed의 상태를 추적함으로서 모니터링할 수 있다.

버퍼 풀에 들어가기 위해 대기하고 있는 큐의 수
버퍼 풀의 용량이 충분하지 못하면 앞의 플러시 이벤트가 발생할 때까지 기다린다. 이런 상황이 얼마나 발생하는 지 카운트하는 것은 매우 중요하다. 이런 일이 자주 발생한다는 것은 현재 버퍼 풀의 크기가 요구량에 비해 작게 설정되어 있다는 뜻이다. 이는 innodb_ buffer_pool_wait_free를 추적함으로써 모니터링할 수 있다.

InnoDB 로그 파일의 설정

InnoDB는 바이너리 로그 파일을 반드시 생성해야 하며 로그 파일과 관련된 설정 역시 성능에 큰 영향을 미치게 된다. MySQL 데이터베이스 관리자로서 InnoDB를 관리하려면 로그 파일과 관련해 몇 가지 결정해야 할 문제가 있다. 먼저 몇 개의 로그 파일을 만들지 결정해야 한다. 기본으로 설정되어 있으며 최소 값은 2이다. 더 많은 로그 파일을 만들려면 innodb_log_files_in_group 설정을 수정하면 된다.

몇 개의 로그 파일을 생성할지 결정되었다면 로그 파일의 용량을 결정해야 한다. Innodb_log_file_size로 설정할 수 있고 기본 값은 5MB로 되어 있다. 이는 작은 데이터베이스를 위해서는 충분한 값이다. 하지만 기업에서 사용하기에는 훨씬 큰 용량이 필요하다. 로그 파일이 작게 설정되었을 경우에는 자주 메모리 기반의 버퍼 풀과 디스크 기반의 로그 파일간의 체크포인트 생성 작업이 이뤄진다. 이는 InnoDB 성능을 매우 떨어뜨리는 주범이 된다. 일반적으로 적당한 로그 파일의 크기는 전체 버퍼 풀 크기를 앞서 설정한 로그 파일의 개수로 나눈 값이다. 예를 들어 버퍼 풀 크기가 180MB이고 innodb_ log_files_in_group을 3으로 설정했다면 적당한 innodb_log_file_size는 60MB가 된다.

로그 파일의 수를 몇 개로 하고 각각의 용량을 얼마로 할지를 정했다면 이제 innodb_log_buffer_size를 설정해야 한다. 로그 버퍼는 디스크로 쓰기 전 메모리에 트랜잭션 정보를 담아두기 위한 버퍼 메모리의 크기를 말한다. 1MB부터 8MB까지 설정할 수 있으며 이 용량이 클수록 디스크의 사용이 줄어들어 성능이 향상되지만 그만큼 갑작스러운 시스템 다운이 발생했을 때 손실되는 트랜잭션의 양도 늘어난다. 메모리가 충분히 많고 특별한 사고 위험이 없다면 크게 잡으면 잡을수록 좋다. 일반적으로 8MB를 추천한다. 마지막으로 COMMIT가 수행되었을 때 로그 버퍼와 파일이 어떤 작업을 하게 될지를 결정해야 한다. Innodb_flush_log_at_trx_commit 설정은 다음과 같은 옵션을 제공한다.

• 디스크에 바로 쓰기 : 가장 안전한 방법이지만 가장 느린 방법이다. 1로 설정하면 디스크에 바로 쓰게 된다.

• 조금 기다린 후 디스크에 쓰기 : 0 또는 2를 설정할 수 있으며 0으로 설정할 경우 commit의 수행 여부와 상관없이 매초 로그 버퍼가 디스크에 기록하게 된다. 2로 설정하면 commit이 수행되면 강제로 로그 버퍼를 로그 파일에 쓰게 만들지만 1초가 지나기 전에는 디스크에 저장되지 않는다. 0으로 설정할 경우 성능은 많이 향상되지만 1초 간의 트랜잭션 정보는 잃을 위험을 동반한다.

InnoDB 로그 파일의 모니터링과 튜닝

MySQL은 5.0.2 버전 이후로 서버에서 볼 수 있는 상태 정보를 엄청나게 많이 늘렸다. 이를 통해 사용자는 데이터베이스 내부의 상황을 더욱 자세히 파악할 수 있게 되었다. MySQL Administrator와 함께 세밀한 튜닝이 가능해 졌다. 새로 추가된 상태 정보들을 통해 로그 파일을 모니터링하고 이를 통해 튜닝 포인트들을 점검해보자.

로그 파일 쓰기 요청
계속해서 변하는 값인 innodb_log_write_requests를 추적함으로써 파악할 수 있다. 이를 모니터링함으로써 애플리케이션이 얼마나 자주 로그 파일의 쓰기를 요청하는지 파악할 수 있다

로그 파일 쓰기 횟수
첫 번째 그래프는 로그 파일 쓰기 요청을 추적하고 이 그래프에서 innodb_log_writes를 추적함으로써 실제적으로 얼마나 많은 쓰기가 이뤄지는지 파악할 수 있다. 첫 번째와 두 번째 그래프 사이에 눈에 띄게 많은 랙이 존재한다면 이를 통해 로깅이 병목 현상을 일으키고 있음을 알 수 있다.

로그 버퍼 웨이팅InnoDB는 로그 버퍼에 쓰기위해 기다리는 경우가 발생할 때마다 계속해서 innodb_log_waits의 값을 올리게 된다. 이러한 증상이 자주 발생하는 주원인은 실제의 요청량에 비해 로그 버퍼가 지나치게 작게 설정되어 있기 때문이다. 이런 증상은 특히 대용량의 정보를 로딩하거나 갑자기 트랜잭션이 증가할 때 발생한다. 이런 증상이 자주 발생한다면 innodb_log_buffer 설정을 증가시켜주는 것이 좋다.