10.5.9 Optimizing InnoDB Configuration Variables

10.5.9 InnoDB Configuration Variables 최적화

서버에 가벼우면서 예측 가능한 부하가 있는 경우와, 항상 최대 용량에 가까운 상태로 실행되거나 주기적으로 높은 활동이 발생하는 서버의 경우에 따라 최적의 설정은 서로 다릅니다.

InnoDB 스토리지 엔진은 많은 최적화를 자동으로 수행하기 때문에, 많은 성능 튜닝 작업은 데이터베이스가 잘 동작하는지 모니터링하고, 성능이 떨어질 때 구성 옵션을 변경하는 작업으로 이루어집니다. 자세한 InnoDB 성능 모니터링에 대한 정보는 Section 17.16, “InnoDB Integration with MySQL Performance Schema”를 참조하십시오.

수행할 수 있는 주요 구성 단계는 다음과 같습니다:

• 빈번한 작은 디스크 쓰기를 피하기 위해, 어떤 종류의 데이터 변경 작업에 대해 InnoDB가 변경된 데이터를 버퍼링할지 제어합니다. Configuring Change Buffering를 참조하십시오. 체인지 버퍼링을 활성화하면 I/O 바운드 워크로드에서 더 나은 성능을 제공할 수 있지만, 복구, 대량 적재 또는 버퍼 풀 리사이징 동안 문제를 일으킬 수 있습니다. (MySQL 8.4부터 기본값인) 비활성화 상태는 성능을 낮출 수는 있어도 안정성을 보장하는 데 도움이 됩니다.

• innodb_adaptive_hash_index 옵션을 사용하여 적응형 해시 인덱싱 기능을 켜고 끕니다. 자세한 내용은 Section 17.5.3, “Adaptive Hash Index”를 참조하십시오. 이 설정은 비정상적인 활동이 있는 기간 동안 변경한 후, 원래 설정으로 되돌릴 수 있습니다.

• 컨텍스트 스위칭이 병목인 경우, InnoDB가 처리하는 동시 스레드 수에 제한을 둡니다. Section 17.8.4, “Configuring Thread Concurrency for InnoDB”를 참조하십시오.

• InnoDB가 리드 어헤드 작업을 통해 수행하는 프리페칭 양을 제어합니다. 시스템에 사용되지 않는 I/O 용량이 있을 때, 더 많은 리드 어헤드는 쿼리 성능을 향상시킬 수 있습니다. 너무 많은 리드 어헤드는 부하가 큰 시스템에서 주기적인 성능 저하를 유발할 수 있습니다. Section 17.8.3.4, “Configuring InnoDB Buffer Pool Prefetching (Read-Ahead)”를 참조하십시오.

• 기본값으로 I/O 서브시스템이 완전히 활용되지 않는 하이엔드 I/O 서브시스템을 사용하는 경우, 읽기 또는 쓰기 작업을 위한 백그라운드 스레드 수를 늘립니다. Section 17.8.5, “Configuring the Number of Background InnoDB I/O Threads”를 참조하십시오.

• InnoDB가 백그라운드에서 수행하는 I/O 양을 제어합니다. Section 17.8.7, “Configuring InnoDB I/O Capacity”를 참조하십시오. 주기적인 성능 저하를 관찰하는 경우, 이 설정을 축소할 수 있습니다.

• InnoDB가 특정 유형의 백그라운드 쓰기를 수행하는 시점을 결정하는 알고리즘을 제어합니다. Section 17.8.3.5, “Configuring Buffer Pool Flushing”를 참조하십시오. 이 알고리즘은 일부 유형의 워크로드에는 적합하지만 그렇지 않은 경우도 있으므로, 주기적인 성능 저하를 관찰하면 이 기능을 비활성화할 수 있습니다.

• 멀티코어 프로세서와 그 캐시 메모리 구성을 활용하여 컨텍스트 스위칭 지연을 최소화합니다. Section 17.8.8, “Configuring Spin Lock Polling”을 참조하십시오.

• 테이블 스캔과 같은 1회성 작업이 InnoDB 버퍼 캐시에 저장된 자주 액세스되는 데이터를 방해하지 않도록 합니다. Section 17.8.3.3, “Making the Buffer Pool Scan Resistant”를 참조하십시오.

• 신뢰성과 크래시 복구에 의미 있는 크기로 로그 파일을 조정합니다. InnoDB 로그 파일은 크래시 이후 긴 시작 시간을 피하기 위해 종종 작게 유지되었습니다. MySQL 5.5에서 도입된 최적화는 크래시 복구 과정의 특정 단계를 가속화합니다. 특히 리두 로그를 스캔하고 리두 로그를 적용하는 작업은 메모리 관리 알고리즘의 개선으로 인해 더 빨라졌습니다. 긴 시작 시간을 피하기 위해 로그 파일을 인위적으로 작게 유지해 왔다면, 이제 리두 로그 레코드 재순환으로 인해 발생하는 I/O를 줄이기 위해 로그 파일 크기 증가를 고려할 수 있습니다.

• 특히 멀티 기가바이트 버퍼 풀을 사용하는 시스템에서, InnoDB 버퍼 풀의 크기와 인스턴스 수를 설정합니다. Section 17.8.3.2, “Configuring Multiple Buffer Pool Instances”를 참조하십시오.

• 최대 동시 트랜잭션 수를 늘립니다. 이는 가장 바쁜 데이터베이스의 확장성을 극적으로 향상시킵니다. Section 17.6.6, “Undo Logs”를 참조하십시오.

• 가비지 컬렉션의 한 유형인 퍼지 작업을 백그라운드 스레드로 이동합니다. Section 17.8.9, “Purge Configuration”를 참조하십시오. 이 설정의 결과를 효과적으로 측정하려면, 먼저 다른 I/O 관련 및 스레드 관련 구성 설정을 튜닝하십시오.

• InnoDB가 동시 스레드 간에 수행하는 스위칭 양을 줄여, 바쁜 서버에서 SQL 작업이 대기열에 쌓여 “교통 체증”을 형성하지 않도록 합니다. 고성능 최신 시스템에서는 innodb_thread_concurrency 옵션 값을 대략 32까지 설정하십시오. innodb_concurrency_tickets 옵션 값은 일반적으로 5000 정도로 늘리십시오. 이 옵션 조합은 InnoDB가 한 번에 처리하는 스레드 수에 상한을 설정하고, 각 스레드가 교체되기 전에 상당한 작업을 수행할 수 있도록 하여, 대기 중인 스레드 수를 낮게 유지하고 과도한 컨텍스트 스위칭 없이 작업을 완료할 수 있게 해줍니다.