[Real MySQL] InnoDB 버퍼풀

MySQL은 데이터를 처리하고 캐싱하는 작업 공간으로 메모리를 적극적으로 활용합니다. 컴퓨터 자원의 효율성은 곧 속도를 의미하지만, 성능과 비용 사이에는 늘 트레이드오프(Trade-Off)가 존재합니다. 특히 데이터베이스(DB)는 수평 확장이 비교적 어려운 만큼, 제한된 리소스 내에서 최대의 효율을 뽑아내는 것이 중요하며, 그 핵심이 바로 메모리 관리에서 시작됩니다.

 

InnoDB 버퍼 풀
MySQL의 다양한 글로벌 메모리 영역 중, 실제 쿼리 성능에 가장 결정적인 영향을 미치는 것은 단연 InnoDB 버퍼 풀 (Buffer Pool)입니다.

일반적으로 AWS RDS 파라미터는 DB 인스턴스 메모리의 약 3/4 (75%)를 기본값으로 설정하며, 업계 전문가들은 서버 메모리의 50%에서 80% 사이를 권장합니다.

 

하지만 모든 상황에 적용되는 절대적인 정답은 없습니다. 가장 이상적인 방법은 가용한 리소스 범위 내에서 워크로드에 맞춰 지속적으로 조정하고 최적화해 나가는 것입니다.

 

다만, 한 가지 분명한 것은 InnoDB 버퍼 풀의 값이 너무 낮게 설정될 경우, 성능 저하를 넘어 심각한 병목 현상을 초래할 수 있다는 점입니다. 현재 MySQL 커뮤니티 버전의 기본 설치 값은 아래와 같이 매우 낮게 설정되어 있습니다.

 

SELECT @@innodb_buffer_pool_size / 1024 / 1024;
-- 기본값은 약 128MB

 

Sysbench를 활용한 성능 검증

 

InnoDB 버퍼 풀 크기가 실제 DB 성능에 미치는 영향을 확인하기 위해 Sysbench를 통해 성능 테스트를 진행했습니다. (기존의 단순 Insert/Select 테스트 대신 Sysbench를 사용하니 테스트의 신뢰도와 난이도가 훨씬 향상되었습니다.)

 

 

테스트 환경 및 설정

OS 환경: Ubuntu Desktop (기본 메모리 8GB)

테이블 설정: 20개 테이블, 테이블당 1,000,000개 레코드

워크로드: OLTP Read/Write

테스트 조건: 32 스레드, 120초 동안 실행

 

# 1. Sysbench 테스트 데이터 준비
sysbench oltp_read_write --mysql-db=test_db ... --tables=20 --table-size=1000000 prepare

#2. Sysbench를 한 번 수행하여 캐싱 로드를 해결했습니다.

# 3. 본 테스트 실행 (각 케이스별 웜업 후 동일 조건 수행)
sysbench oltp_read_write \
  --mysql-db=test_db \
  --mysql-user=root \
  --mysql-password=1234 \
  --tables=20 \
  --table-size=1000000 \
  --threads=32 \
  --time=120 \
  --report-interval=10 \
  run > report.txt

 

버퍼 풀 크기 변경 및 재실행

테스트 후, innodb_buffer_pool_size 값을 변경하고 MySQL을 재실행한 뒤, 다시 웜업을 수행하고 동일한 조건으로 테스트를 진행했습니다.

 

설정값	128MB	1024MB
평균 TPS	151s	225s
평균 Latency	211ms	142ms

 

 

단순히 버퍼 풀 크기를 늘리는 것만으로 평균 처리량은 약 50% 증가했고, 평균 응답 시간은 33% 빨라지는 획기적인 성능 개선 효과를 확인할 수 있었습니다. 이 결과는 InnoDB 버퍼 풀이 MySQL 성능 튜닝에서 왜 가장 우선순위가 높은 영역인지 명확하게 보여줍니다.

 

허나 위 테스트를 진행하면서 발생된 문제는 튜닝이 전혀 안되어있는 우분투 기반의 MySQL 기본설정으로 테스트를 하다보니 1G로 변경 후 병목이 발생된 내용이 확인되었습니다. 물론 위 결과적으로도 유의미하지만 단순히 튜닝은 하나의 설정값으로 모든 성능이 해결되는 영역이 아니다보니 여러 방면으로 내용을 확인할 필요가 있는 것 같습니다.

 

여러모로 InnoDB의 중요성은 Real MySQL 8.0에도 나와있으니 꼭 보시는 걸 추천드립니다.