출처: https://gihyo.jp/dev/serial/01/game_mysql/0002
페이지 크기에 대해
MySQL(InnoDB)는 기본 페이지 크기는 16KB로 이외에 8KB과 4KB를 선택할 수 있다(Amazon RDS 등의 공유 인스턴스는 대부분 16KB로 변경 수 없다). 게임 계는 OLTP(On-Line Transaction Processing) 타입으로 불리는 타입의 시스템이다, 일반적으로 1 사용자의 데이터를 읽고 기록하는 경우가 많다. 즉, 세세한 데이터 액세스가 많은 시스템이다. 이러한 시스템의 경우 작은 페이지 크기가 더 유리할 가능성이 높다.
작은 페이지 크기는 물론 단점도 있다. 그것은 작은 페이지 크기로 하면 사용할 수 없는 공백이 많아진다는 것이다.
예를 들어, 평균 레코드 길이(TEXT, BLOB 등의 데이터 타입은 다른 페이지에 저장 되기 때문에 이것 이외)가 2,500Byte로 페이지 크기가 4KB인 것을 선택하면 1 페이지에 거의 1 레코드 만 저장 되어서 메모리나 HDD의 37. 5%를 이용 하지 못하게 된다. 반대로, 페이지 크기가 클수록 데이터가 세밀하게 작성 되어 메모리나 HDD의 이용 효율이 오르기 때문에, 대량의 데이터를 읽어서 집계하는 처리에는 적합하다.
페이지 크기는 고려하지 않고 기본 값을 그대로 사용할 수 있는 것이 많지만, 매우 성능에 영향을 주기 때문에 잘 고려해야한다.
로그 파일의 크기
게임 계에서는 이벤트나 캠페인 시 액세스가 집중한다. 액세스 집중 시 로그 파일이 넘쳐서, HDD에 플래시(실제 데이터 쓰기)가 대량으로 발생하면 서버의 부하는 폭발적으로 증가한다.
이벤트나 캠페인 시에 올라가는 크기를 확인하고 설정한다.
로그 파일에 기록 타이밍
예를 들어, 이벤트 및 캠페인 시에는 초당 수만 회 라는 쓰기가 발생할 수 있으며, 로그 파일을 크게하여 HDD에 플래시가 일어나지 않도록 설정해도 과부하가 걸릴 수 있다. 이런 경우에는 "innodb_ flush_ log_ at_ trx_ commit" 라는 매개 변수를 2로 설정하여 로그 파일에 기록 타이밍을 1초에 1회로 하는 것으로 HDD에 쓰기 부하를 줄일 수 있다(기본 매개 변수는 1로 커밋마다 기록된다) . 그러나 HDD에 이중으로 지연 쓰기를 하여서, 최대로 초당 업데이트 된 데이터가 분실 될 가능성도 있다.
그러나 최근의 온라인 게임에서는 그림 1과 같이 "RDBMS에 쓰기는 배틀 종료 시에 한 번 실시' 라는 게임도 증가 하고 있다.
(redis와 같은 캐시 시스템 사용)
이러한 게임에서는 RDBMS와 클라이언트와 AP 서버 간의 데이터 불일치가 항상 부정합된 상태로 운용되고 있기 때문에 사용자 입장에서 보면, 장애가 발생 했을 때 수십 초에서 수분의 롤 백이 일어나므로 로그 파일에 기록을 1초에 1번 해도 사용자 가치는 크게 달라지지 않는다고 생각한다. 그래서 "innodb_ flush_ log_ at_ trx_ commit = 2' 라는 설정도 검토하면 좋다.
그러나 청구에 대한 처리는 커밋 시점에 로그 파일에 기록되도록 한다. "innodb_ flush_ log_ at_ trx_ commit = 1" 로 설정한 다른 데이터베이스에서 하고, 커밋된 데이터의 분실을 방지한다.
로그 버퍼 크기
"innodb_ flush_ log_ at_ trx_ commit = 2" 로 로그 파일에 기록 타이밍을 1초에 1번 하는 경우 에서 이 버퍼 크기는 이전 보다 크게 설정해야한다. 버퍼가 부족할 때는 1초가 지나지 않아도 기록하게 되므로, "innodb_ flush_ log_ at_ trx_ commit = 2" 하는 의미가 없어진다. 때문에 1 초에 기록되는 로그가 충분히 들어갈만큼의 크기를 설정한다.
각 워크 메모리(스레드 버퍼) 크기
세션 단위로 사용되는 워크 메모리의 크기이다. 설정 값과 최대 동시 연결 수와의 곱셈이 최대 사용량이 되므로, 너무 할당 하지 않도록 주의한다. 각 처리를 실시 할 양 이상으로 할당하지 않도록 한다.
데이터 버퍼 크기
"innodb_ buffer_ pool_ size" 라는 파라미터로 조정한다. 이것은 튜닝의 기본이 되는 파라미터로 가능한 한 크게 잡는다. " 실제 메모리의 80 %를 기준으로" 등으로 되어 있는 것이 많지만, 메모리의 증감이 쉬운 클라우드 서비스를 이용하고 있으면 80%라는 수치에 의미가 없다. 따라서 기준이 되는 수치로는 " 캐시 적중률" 이 좋다. 게임에 한정하지 않고 데이터베이스를 오랫동안 운영하고 있으면 데이터가 늘어나서 캐시 적중률이 떨어지는 경향이 있기 때문에, 목표로 하는 캐시 적중률이 되도록 설정을 정기적으로 검토한다.
비즈니스 계에서는 95~99%를 목표 치로 조정하는 것이 많지만, 목표 치는 게임(시스템)에 의해 달라진다. 예를 들어, 일련의 조정을 마치고 만족스러운 성능이 나온 시점의 캐시 적중률을 목표로 하면 성능을 유지하기 쉬울 것이다.
실제 메모리를 늘려도 " 매개 변수를 수정하지 않는한 확장한 메모리는 사용할 수 없다" 라고 하므로 꼭 주의해야한다.