MySQL 데이터베이스 최적화, MySQL 성능을 200%로 2
MySQL 엔진 튜닝 MyISAM & InnoDB
MySQL의 수많은 장점 중 가장 큰 장점을 꼽는다면 하나의 데이터베이스 시스템 안에 다양한 스토리지 엔진이 있다는 것이다. 그 중 대표적인 것이 MyISAM과 InnoDB 엔진이다. MyISAM은 주로 트랜잭션이 필요 없고 Select 쿼리가 많은 데이터베이스에 쓰이며 InnoDB는 트랜잭션과 DB를 변경하는 작업이 많은 데이터베이스에 사용된다. MySQL이라는 하나의 데이터베이스 시스템 안에 있는 엔진이지만 두 스토리지 엔진은 완전히 별개의 튜닝 요소들을 가지고 있다. 이번 호에서는 이 두 스토리지 엔진의 특성 및 최적화에 대해 알아보자.
MySQL은 처음에는 Isam 스토리지 엔진으로 시작해 MyISAM으로 발전했고 3.x 버전에서 트랜잭션에 대한 요구가 대두되면서 Innobase의 InnoDB 엔진을 인수해 트랜잭션과 로우 레벨 락킹(row level locking)을 지원하기 시작했다. 또 그 이후 NDB 스토리지 엔진을 인수해 메모리 기반의 클러스터 기능을 추가했다. 이처럼 서로 태생이 다른 여러 스토리지 엔진이 하나의 데이터베이스 시스템 안에서 공존하며 함께 동작할 수 있다는 것이 MySQL의 큰 특징 중 하나로 자리 잡았다. 앞에서 언급했듯이 각 스토리지 엔진이 독립적인 데이터베이스로 출발했기에 현재도 MySQL의 설정파일 내부에는 각 스토리지 엔진에 대한 설정도 역시 분리되어 있으며 MySQL의 성능은 사용하는 스토리지 엔진별로 튜닝하는 것으로 큰 차이를 보인다.
MyISAM 스토리지 엔진 튜닝
먼저 MySQL이 현재의 명성을 얻게 만든 MyISAM 엔진에 대한 튜닝부터 알아보자. 데이터베이스의 최적화를 간단히 정의하자면 어떻게 하면 디스크의 사용을 줄이고 메모리를 효율적으로 사용할 수 있는가라고 할 수 있다. MyISAM 스토리지 엔진도 디스크의 사용을 줄이고 최대한 많은 정보를 적절한 메모리에 올려서 사용하기 위한 여러 가지 파라미터들을 가지고 있다. 그 중 가장 중요한 파라미터인 키 캐시(Key Cache)는 바로 이런 목적을 위해 마련되었으며 그 중 인덱싱된 정보 처리에 중점을 두고 있다. MyISAM 스토리지 엔진에서 키 캐시 튜닝은 전체 튜닝의 80% 이상을 차지한다고 할 수 있다. 먼저 키 캐시의 동작 방식과 튜닝에 대해 자세히 알아보자.
MyISAM 키 캐시의 동작 방식
키 캐시란 관리자가 정의하고 설정할 수 있는 하나 혹은 그 이상의 테이블의 인덱스 정보를 저장할 수 있는 메모리 블럭을 말한다. 특정 테이블로부터 인덱스 정보를 생성, 수정하거나 가져오려고 할 때 MySQL은 먼저 관련된 정보를 메모리로부터 읽어올 수 있는지를 살펴본다. 만약 캐시로부터 정보를 읽어올 수 있다면 키 캐시를 통해 읽기나 쓰기 작업을 매우 빨리 처리할 수 있다. 또는 캐시로부터 정보를 얻을 수 없는 경우가 있다. 예를 들어 데이터나 인덱스 정보가 변경되었을 때 MySQL은 새로운 값을 디스크에 쓴 후 키 캐시에서 교체할 항목들을 정의한 후 새로운 정보로 대체한다. 다음은 키 캐시에 대한 몇 가지 중요한 사항들이다.
• 모든 인덱스 블럭은 명시적인 타임 스템프를 가진다 : MySQL은 어떤 블럭이 가장 오래되었는지 파악하기 위해 블럭을 큐 방식으로 저장한다. 이것은 키 캐시가 한정된 공간을 가지고 있고 새로운 블럭을 저장하기 위해 현재 존재하는 블럭을 밀어내야 하기에 매우 중요하다.
• 블럭은 캐시에 있는 동안 변화될 수 있다 : 만약 특정인의 성을 김에서 금으로 고치고 해당 컬럼이 인덱스되어 있는 경우에 키 캐시의 인덱스 블럭 또한 수정된다. 그리고 언제든지 키 캐시의 블럭은 제거될 수도 있기에 수정된 정보를 바로 디스크에 저장한다.
• 충분한 메모리를 가지고 있다면 MySQL이 기본으로 제공하는 키 캐시 외에도 여러 개의 추가적인 키 캐시를 가질 수 있다 : 이 기능은 MySQL 4.1 버전에 새롭게 도입된 기능이다. 예를 들어 하나의 키 캐시는 매우 변화가 많은 트랜잭션이 주로 이뤄지는 테이블들을 위한 용도로 사용하고 다른 키 캐시는 의사 결정을 위해 사용되며 데이터의 변화가 별로 없는 테이블들을 위한 용도로 사용한다.
• 동시접속률을 증가시키기 위해 여러 개의 쓰레드가 하나의 캐시를 동시에 사용할 수 있다 : 물론 하나의 쓰레드가 캐시를 수정하는 경우 다른 쓰레드들은 수정이 완료될 때까지 잠시 기다린다.
• 키 캐시 블럭의 교체를 위해 기본적인 큐 방식 이외에도 추가적으로 매우 복잡한 알고리즘을 제공한다 : 이른바 ‘중간 삽입 전략(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
<표 1> MySAM의 각종 메모리 관련 파라미터
| 범위 | 파라미터 | 설명 |
| 서버 전체가 공유함 | Key_buffer_size | 인덱스를 메모리에 저장하는 버퍼의 크기 |
| Table_cache | 전체 쓰레드가 사용할 오픈 가능한 테이블의 수 | |
| Thread_cache_size | 재사용을 위해 캐싱될 쓰레드의 수 | |
| 각 쓰레드 별로 사용됨 | myisam_sort_buffer_size | 테이블 repair, Alter table, load data에 사용되는 버퍼 메모리 크기 |
| join_buffer_size | 조인을 위한 메모리 버퍼 크기 | |
| record_buffer | 순차적인 검색을 위해 사용되는 메모리 버퍼 크기 | |
| record_rnd_buffer | Order by 절을 사용하는 경우 디스크 사용을 피하기 위하여 사용하는 메모리 버퍼 크기 | |
| sort_buffer | Order by와 group by에 사용되는 메모리 버퍼 크기 | |
| tmp_table_size | Group by시 디스크를 사용하지 않고 임시 테이블을 만들기 위해 사용되는 메모리 크기 |
키 캐시 쓰기 적중률
이 그래프는 키 캐시 쓰기 요청과 실제로 디스크에 쓰이는 키 블럭간의 상관관계를 볼 수 있다. 계산식은 다음과 같다.
계산식 = 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 설정을 증가시켜주는 것이 좋다.
<화면 3> 로그 파일 모니터링을 위해 구성해 놓은 MySQL Ad,inistrator의 모습
로그 파일과 운영체제간의 상호작용
변경된 정보는 결국 로그 파일로 디스크에 저장되고 이는 결국 운영체제의 파일 시스템과 상호작용을 하게 된다. 그러므로 InnoDB와 파일 시스템 간에 벌어지는 일들을 모니터링하는 작업도 매우 중요하다. <화면 3>의 두 번째 그룹의 첫 번째 그래프는 파일 시스템의 병목으로 로그 파일에 쓰는 것이 늦춰지는 것을 파악한다. 이는 innodb_ os_log_pending_writes를 통해 추적해 볼 수 있다. 그리고 다음 두 가지의 그래프는 실제적인 디스크 쓰기를 담당하는 Fsync() 함수를 innodb_os_log_fsyncs를 통해 추적함으로써 실제적인 쓰기 요청이 얼마나 일어나는지와 fsync()의 실행이 늦춰지는 경우는 얼마나 있는지를 innodb_os_log_fsyncs_pending을 통해 파악함으로써 현재 innodb 시스템이 얼마나 I/O의 병목현상 없이 잘 실행되고 있는지를 파악할 수 있다.
낚시하는 방법을 배우자
공개된 여러 튜닝 정보들을 보면 각각의 튜닝이 어떤 내부 구동 원리를 통해 이뤄지는가를 설명하기보다는 각 항목에 대해 구체적인 추천 수치만을 제시함으로써 일회성의 수동적인 튜닝에 그치는 경우가 많다. 그래서 이번 2회에 걸친 연재에서는 구체적인 수치를 제시하기 보다는 각 항목들이 데이터베이스 내부에서 어떤 역할을 하며 수치를 변경하는 것이 어떤 결과를 낳게 되는지 그리고 모니터링을 통해 이를 실제로 확인할 수 있게 하는 것을 주로 살펴봤다. 이번 연재에서 설명이 미흡하거나 따라하기 힘든 부분도 많아 아쉬움이 남지만 MySQL이라는 데이터베이스의 활용에 작은 도움이라도 되었으면 한다.
댓글