Mysql에서 기본으로 사용되는 스토리지 엔진은 보통 MyISAM다. 전통적으로 많이 사용되어 온 형태로, 데이터 변경이 크게 없고 읽기가 많은 경우-즉 혼자 글을 쓰고 공개하는 블로그 등에서 효율적이며, CPU나 메모리의 성능보다는 스토리지의 성능에 더 영향을 받는다고 한다. 그리고 InnoDB는 트랜잭션이니 뭐니 여러 기능이 추가/향상되어 나온 엔진으로, CPU와 메모리에 비례해 성능이 향상되며 읽고 쓰기가 많은 경우에 유용하다. 가장 큰 차이는 트랜잭션의 지원 유무지만, xe를 쓰는 우리에게 있어서 가장 중요한 차이점은 DB에서 데이터를 변경할 경우 테이블 단위로 락을 거는 MyISAM과 달리 행 단위(row-Level)로 락을 건다는 것.
사실 제로보드4 시절엔 DB 상태가 어쩌고에 관심도 없었고, 그런 거 몰라도 빠릿빠릿하게 잘 굴러가던 게 제로보드라 신경 쓸 필요도 없었다. 그렇다 보니 제로보드의 게시물/덧글 db가 어떻게 되어있었는지는 모르겠는데, 최근 xe의 속도를 이야기하며 가장 문제시되는 부분이 게시물/덧글을 xe_comments와 xe_documents 테이블 하나씩에 그대로 전부 때려박는다는 것이다. 그래서 앞서 말한 MyISAM의 table-level lock, 테이블 단위 락이 여기서 문제가 된다. DB에서 테이블의 데이터를 변경하는 경우, 동시에 다른 사용자가 해당 데이터를 변경하거나 해서 오류가 발생하지 않도록 데이터를 잠그게 되는데, xe는 모든 걸 하나의 테이블에 때려박아둔 덕분에 이 큰 테이블 자체가 잠겨버리게 된다. 대다수의 세션이 Lock wait 상태에 빠질 수 있는 것. 실제로 게시물도 유동인구도 몇 안되는 절대넷마져도 간간히 접속이 끔찍하게 늦어지는 상태였고, 실제 슬로우 쿼리 로그도 xe_documents의 겨우 게시판 두 개에 쿼리 날리는 와중에 걸리는 부하였다.
이를 해결하기 위해 게시물 카운트를 자른다거나 무슨 캐시를 먹인다거나 여러 복잡한 방법도 시도도 많은 모양인데, 웹이고 디비고 뭐고 지식이 전무하다 보니 봐도 쫓아갈 수가 없었고, 가장 간단해보이는 해결책이 DB엔진을 InnoDB로 변경하는 것이었다. InnoDB는 데이터 변경에 대해 테이블 자체를 잠궈버리는 MyISAM과 달리 row-Level, 행 단위로만 데이터를 잠그기 때문에 테이블에 데이터 변경이 일어나고 있어도 동시에 다른 데이터 액세스가 가능하다. 물론 그 덕분에 처리해야 할 양이 상당히 늘어나는 게 부담이긴 하지만, 위젯 출석 로또 글쓰기 등 다양한 쓰기 활동이 동시에 일어나는 상황에서는 훨씬 유용하다고 생각한다. 게다가 그렇게 큰 규모도 아니고.
사용하던 MySIAM 테이블을 InnoDB로 변경하는 건 간단했다. 혹시를 대비해 일단 디비 전체를 백업해두고, phpmyadmin의 쿼리 메뉴에서
좀 지켜봐야 알겠지만, 지금 당장은 꽤 빠른 듯한 착각이 좀 든다. 아참, 내부 게시판을 포함해 30~40MB 남짓했던 걸로 기억하는 DB 용량이 엔진 변경 후 갑자기 90MB 가까이 뛰어 깜짝 놀랐는데, InnoDB의 특성이라는 것 같다. 약 2배 정도 몸집이 불어난다.
사실 제로보드4 시절엔 DB 상태가 어쩌고에 관심도 없었고, 그런 거 몰라도 빠릿빠릿하게 잘 굴러가던 게 제로보드라 신경 쓸 필요도 없었다. 그렇다 보니 제로보드의 게시물/덧글 db가 어떻게 되어있었는지는 모르겠는데, 최근 xe의 속도를 이야기하며 가장 문제시되는 부분이 게시물/덧글을 xe_comments와 xe_documents 테이블 하나씩에 그대로 전부 때려박는다는 것이다. 그래서 앞서 말한 MyISAM의 table-level lock, 테이블 단위 락이 여기서 문제가 된다. DB에서 테이블의 데이터를 변경하는 경우, 동시에 다른 사용자가 해당 데이터를 변경하거나 해서 오류가 발생하지 않도록 데이터를 잠그게 되는데, xe는 모든 걸 하나의 테이블에 때려박아둔 덕분에 이 큰 테이블 자체가 잠겨버리게 된다. 대다수의 세션이 Lock wait 상태에 빠질 수 있는 것. 실제로 게시물도 유동인구도 몇 안되는 절대넷마져도 간간히 접속이 끔찍하게 늦어지는 상태였고, 실제 슬로우 쿼리 로그도 xe_documents의 겨우 게시판 두 개에 쿼리 날리는 와중에 걸리는 부하였다.
이를 해결하기 위해 게시물 카운트를 자른다거나 무슨 캐시를 먹인다거나 여러 복잡한 방법도 시도도 많은 모양인데, 웹이고 디비고 뭐고 지식이 전무하다 보니 봐도 쫓아갈 수가 없었고, 가장 간단해보이는 해결책이 DB엔진을 InnoDB로 변경하는 것이었다. InnoDB는 데이터 변경에 대해 테이블 자체를 잠궈버리는 MyISAM과 달리 row-Level, 행 단위로만 데이터를 잠그기 때문에 테이블에 데이터 변경이 일어나고 있어도 동시에 다른 데이터 액세스가 가능하다. 물론 그 덕분에 처리해야 할 양이 상당히 늘어나는 게 부담이긴 하지만, 위젯 출석 로또 글쓰기 등 다양한 쓰기 활동이 동시에 일어나는 상황에서는 훨씬 유용하다고 생각한다. 게다가 그렇게 큰 규모도 아니고.
사용하던 MySIAM 테이블을 InnoDB로 변경하는 건 간단했다. 혹시를 대비해 일단 디비 전체를 백업해두고, phpmyadmin의 쿼리 메뉴에서
alter table 테이블명 type=InnoDB;을 날려서 변경했다. 그리고 xe의 디비 설정도 수정해야 한다. /files/config/db.config.php 를 열어서
$db_info->master_db = array('db_type' => 'mysql_innodb','db_port' => '3306','db_hostname' => 'localhost','db_password' => '암호','db_database' => '이름','db_userid' => '이름','db_table_prefix' => 'xe_');db_type 부분도 mysql_innodb로 수정한다.
$db_info->slave_db = array(array('db_type' => 'mysql_innodb','db_port' => '3306','db_hostname' => 'localhost','db_password' => '암호','db_database' => '이름','db_userid' => '이름','db_table_prefix' => 'xe_'));
좀 지켜봐야 알겠지만, 지금 당장은 꽤 빠른 듯한 착각이 좀 든다. 아참, 내부 게시판을 포함해 30~40MB 남짓했던 걸로 기억하는 DB 용량이 엔진 변경 후 갑자기 90MB 가까이 뛰어 깜짝 놀랐는데, InnoDB의 특성이라는 것 같다. 약 2배 정도 몸집이 불어난다.
티스토리 초대장 충전 기준에 대한 - 고객센터의 답변!
