[ 튜닝 ] innodb 퍼포먼스 튜닝 – 시스 존 
 by 서진우 · Published 2006 년 11 월 24 일 · Updated 2014 년 12 월 24 일 
 InnoDB 는 MyISAM 과 공유 하 는 메모리 도 있 지만 대개 별도 의 Buffer pool 을 가지 고 있 습니다 . 즉 , MyISAM 의 경우 record _ buffer 나 key _ buffer 를 사용 하 지만 InnoDB 는 innodb _ additional _ mem _ pool _ size 나 innodb _ buffer _ pool _ size 같 은 별도 의 메모리 를 사용 합니다 . 따라서 InnoDB 전용 DB 를 구성 한다면 key _ buffer 나 record _ buffer 에 너무 많 은 메모리 를 할당 해서 는 안 되 겠 습니다 . 
 중요 한 메모리 관련 파라미터 를 몇 가지 설명 하 겠 습니다 . 
 1 . innodb _ buffer _ pool _ size : MyISAM 의 경우 Buffer pool 이 없 습니다 . 따라서 OS 자체 의 buffer cache 를 사용 하 며 OS 의 flush 메카 니즘 에 따라서 디스크 에 쓰 게 됩니다 . 
 MyISAM 의 경우 Key _ buffer 나 record _ buffer , sort _ buffer 외 에 도 OS 의 버퍼 캐시 를 위해 충분 한 메모리 를 남겨 놓 아야 하 겠 습니다 . OS 의 버퍼 캐 쉬 는 OS 가 자동 으로 사이즈 를 동적 으로 할당 하 며 free 명령어 로 상태 를 확인 할 수 있 습니다 . 
 그러나 InnoDB 는 오라클 처럼 별도 의 데 이타 를 위한 읽 기 쓰 기 버퍼 메모리 를 가지 고 있 으며 그것 이 innodb _ buffer _ pool _ size 입니다 . innodb _ buffer _ pool _ size 는 색인 과 데 이타 에 대한 Cache 데 이타 를 가지 고 있 습니다 . 그래서 MyISAM 처럼 Key _ buffer 가 필요 없 는 겁니다 . 
 보통 우리 가 SQL 쿼리 로 질의 를 수행 하 면 DBMS 는 먼저 이 buffer _ pool 에서 데 이타 를 검색 하 고 없 을 경우 디스크 에서 읽 어서 buffer _ pool 에 올려 놓 으며 이것 을 \\ 물리 적 인 읽 기 \\ 라고 합니다 . 반면 에 이미 buffer _ pool 에 데이 타가 존재 하 여 디스크 를 직접 읽 지 않 아도 되 는 경우 를 \\ 논리 적 읽 기 \\ 라고 합니다 . 
 당연히 논리 적 읽 기 가 더 빠르 므로 buffer _ pool 의 사이즈 를 크 게 설정 할 수록 유리 합니다 . 그러나 무한정 크기 를 늘릴 경우 스와핑 을 유발 할 수 있 으므로 자신 의 현재 메모리 에서 계산 하 여야 합니다 . 적당 한 사이즈 는 자신 의 메모리 의 50 %- 80 % 입니다 . 
 참고 로 x 86 머신 에서 는 이 innodb _ buffer _ pool _ size 를 2 G 이상 설정 할 수 없 으니 참 고 바랍니다 . 
 2 . innodb _ additional _ mem _ pool _ size : 이 메모리 는 \\ 데 이타 딕셔너리 정보 \\ 나 \\ 내부 의 데 이타 구조 \\ 에 대한 정보 를 담 는 메모리 입니다 . 
 보통 2 M 정도 가 적당 하 지만 아주 많 은 테이블 을 사용 한다면 늘려 주 어야 합니다 . 
 이 메모리 공간 이 부족 하 면 InnoDB 는 OS 의 메모리 를 할당 해서 사용 하 기 시작 하 며 error log 에 warning 메시지 를 남기 게 됩니다 . 
 3 . innodb _ flush _ log _ at _ trx _ commit : 이 파라미터 는 insert 나 update 등 데 이타 삽입 과 밀접 한 관계 가 있 습니다 . 
 즉 , commit 을 하 였을 경우 그 즉시 commit 된 데 이타 를 log file 에 기록 할 것 인지 아닌지 를 설정 하 는 옵션 입니다 . 즉시 로그 파일 에 기록 할 경우 급작스런 정전 같 은 경우 데 이타 손실 을 막 을 수 있 지만 매번 로그 를 기록 해야 하 므로 속도 가 상당히 저하 됩니다 . 
 만약 약간 의 데 이타 손실 을 감내 할 수 있 다면 \\ 0 \\ 으로 설정 하 시 기 바랍니다 . 
 \\ 0 \\ 으로 설정 할 경우 매 트랜잭션 마다 데 이타 를 로그 에 기록 하 지 않 으므로 I / O 부하 를 줄일 수 있 으며 여러 트랜잭션 을 모아서 한 번 의 디스크 I / O 로 기록 하 므로 I / O 횟수 자체 도 줄어듭니다 . 
 실재 로 테스트 결과 이 옵션 의 설정 에 따라 극 적 으로 insert 성능 이 달라지 는 것 을 목격 하 였 습니다 . 
 디폴트 설정은 \\ 0 \\ 즉 off 상태 입니다 . ( commit 즉시 로그 에 기록 하 지 않 음 ) 
 4 . innodb _ log _ file _ size : 이 파일 은 트랜잭션 을 기록 하 는 로그 파일 의 사이즈 를 결정 하 는 옵션 입니다 . InnoDB 는 트랜잭션 을 지원 하 므로 이런 트랜잭션 안정 성 을 위한 로그 파일 이 존재 하 여야 합니다 . 
 처음 에 데 이타 와 색인 을 위한 버퍼 풀 메모리 ( innodb _ buffer _ pool _ size ) 를 언급 하 였 습니다 . 이러 한 버퍼 풀 은 성능 을 위한 것 임 에 틀림없 지만 단점 은 급작스런 정전 같 은 경우 에 버퍼 풀 에 있 는 데 이타 가 손실 된다는 것 입니다 . ( 주로 쓰 기 버퍼 ) 그래서 이러 한 손실 을 방지 하 고자 log file 을 두 게 되 며 , 트랜잭션 commit 이 될 때 마다 로그 에 꼼꼼히 기록 해 놓 고 추후 시스템 다운 이나 정전 같 은 상황 이 발생 할 경우 이 로그 파일 을 근거 로 자동 복구 를 하 게 됩니다 . 
 이 파일 의 사이즈 를 얼마 로 설정 하 느냐 도 아주 중요 한 문제 입니다 . 이 파일 은 트랜잭션 을 기록 하 는 파일 이 므로 이 파일 이 가득차 게 되 면 버퍼 풀 에 있 는 데 이타 를 디스크 에 쓰 도록 지시 하 고 로그 를 초기 화 하 고 다시 써 나가 야 합니다 . 
 즉 로그 파일 은 무한정 커지 는 것 이 아니 라 일정 한 크기 와 갯 수 를 가지 고 순환 식 으로 처리 되 므로 로그 가 초기 화 되 는 시점 에 는 buffer _ pool 의 데 이타 를 디스크 에 기록 하 여야 합니다 . 뒤집 어 말 하 면 이 로그 사이즈 가 작 으면 작 을수록 buffer _ pool 의 내용 을 자주 디스크 에 기록 하 여야 한다는 의미 입니다 . ( checkpoint ) 
 따라서 이 로그 파일 의 사이즈 를 buffer _ pool 의 15 % 정도 로 설정 하 는 것 이 바람직 하 며 경우 에 따라서 는 buffer _ pool 사이즈 정도 로 커질 수 도 있 습니다 . 
 이 로그 파일 의 최대 사이즈 는 모두 합쳐서 < 4 GB 보다 작 아야 한다는 제한 이 있 으며 , 사이즈 가 클 경우 반대 급부 로 시스템 다운 후 재 복구 에 많 은 시간 이 소요 된다는 단점 이 있 습니다 . 
 5 . innodb _ log _ buffer _ size : 이것 은 위 에서 말 한 로그 파일 을 기록 하 기 위한 버퍼 사이즈 입니다 . 커다란 트랜잭션 을 처리 할 경우 크 게 잡 아 주 는 것 이 좋 지만 트랜잭션 이 작 거나 거의 없 다면 크 게 잡 는 것 은 낭비 입니다 . 
 보통 1 M - 8 M 사이 로 설정 하 시 기 바랍니다 . 
 몇 가지 옵션 들 이 더 있 지만 성능 에 가장 극 적 인 영향 을 주 는 것 들 만 언급 했 습니다 . 
 MySQL 3 . 23 . 52 그리고 4 . 0 . 3 버 젼 부터 InnoDB 의 내부 상태 를 모니터링 할 수 있 도록 “ SHOW INNODB STATUS ” 명령어 를 제공 합니다 . 
 현재 버 젼 은 위 의 명령어 를 사용 할 수 없 으므로 
 라는 명령어 를 내리 면 < hostname >. err 파일 에 일정 간격 으로 내부 정보 를 기록 합니다 . 
 위 의 테이블 을 생성 하 라는 명령어 를 입력 하 면 MySQL 엔진 은 그냥 명령어 로 인식 합니다 . 
 모니터링 을 언급 하 는 이유 는 튜닝 을 한번 하 는 것 으로 끝나 는 것 이 아니 라 지속 적 으로 모니터링 하 여 조정 하 여야 한다는 점 을 강조 하 기 위해서 입니다 . 
 분명히 튜닝 은 정답 이 없 습니다 . 따라서 내부 작동 원리 를 정확히 이해 하 고 튜닝 을 했 을 때 효과 를 볼 수 있 습니다 . 
 [ 관리 ] Mysql 기본 tunning 방법 
 [ 문제 해결 ] mysql _ connect 제한 수 초과 에러 
 [ 문제 해결 ] The table is full Error 해결 법 
 Next story [ mysql ] Mysql 튜 팅 및 최적 화 
 Previous story [ 시스템 ] Redhat lm _ sensors 로 시스템 온도 측정 하 기