14.4.1 InnoDB Initialization and Startup Configuration
InnoDB의 구성할 때 가장 처음 결정했던 것은 데이터파일을 어떻게 표현할 것인가와 InnoDB 스토리지 엔진을 위한 메모리를 어떻게 할당할 거인가였다. 당신은 configuration 파일에 값을 넣어 MySQL이 시작하면서 읽도록 할 수 있으며 CLI 옵션으로도 지정할 수 있다.
Overview of InnoDB Tablespace and Log Files
InnoDB 스토리지 엔진에 의해 관리되는 것 중 가장 중요한 디스크 기반의 리소스를 꼽으라면 테이블스페이스 데이터 파일과 로그 파일이다. configuration 파일에서 따로 명시하지 않았다면 MySQL은 자동으로 증가하고 12MB보다 약간 큰 데이터 파일인 ibdata1과 로그파일 2개(ib_logfile0, ib_logfile1)을 데이터 디렉토리에 생성한다. 이 로그 사이즈의 크기는 innodb_log_file_size 파리미터에 의해 결정된다. 좋은 성능을 위해 파라미터의 값을 명시적으로 조절할 필요가 있다. 물론 당신의 하드웨어와 요구사항에 맞게 조절해야 한다.
Considerations for Storage Devices
어떤 케이스에서는 데이터파일이 서로 다른 물리적인 디스크에 위치해야 더 좋은 성능이 나온다. 로그 파일을 데이터 파일과 다른 디스크에 구성하는 것은 매우 자주 쓰이며 효과적인 방법이다. 다음 예제는 어떻게 하는지를 보여준다. 두 개의 데이터 파일을 서로 다른 디스크에 위치시키며 로그 파일 또한 세 번째 다른 디스크에 위치시킨다. InnoDB는 테이블스페이스를 채울 때 데이터파일의 첫 번째 데이터 파일을 사용한다. 그리고 I/O를 향상시키 위해 raw device를 InnoDB의 데이터 파일로 사용할 수도 있다.
Caution
InnoDB는 트랜잭션이 보장되는 엔진이다. 그러나 OS나 하드웨어가 그러한 요구사항을 받아주지 못한다면 무용지물이 된다. 많은 OS와 disk 시스템이 성능을 위해 write 동작을 delay시키거나 reorder 시키고 있다. 어떤 OS에서는 fsync() 시스템 콜이 모든 데이터가플러쉬 될 때까지 기다려야함에도 완료되기 전에 return하는 경우가 있다. 이 때문에 OS crash나 정전등으로 인해 최근 commit 된 데이터가 유실되는 경우나 write 동작이 reorder됨으로써 데이터베이스가 깨지는 경우도 있다. 만약 데이터의 정합성이 중요하다면 프로덕션에 적용하기 전 pull-the-plug 테스트를 해봐라. OS X 10.3 보다 높은 경우 InnoDB는 플러쉬를 위해 특별한 fcntl() 라는 함수를 사용한다. Linux에서는 write-back cache를 비활성화 하는 것을 고려해볼만 하다 (CPU 캐시에만 update하고 메모리에는 update하지 않아 데이터 일관성이 맞지 않을 수 있다)
ATA/SATA 디스크에서는 write-back cache를 비활성화하는 게 불가능할 수도 있다. 어떤 drive나 디스크 컨트롤러에서도 write-back cache를 비활성화하는게 불가능한 경우가 있으니 유의해라.
유저의 데이터를 보호함에 관련하여 복구 능력을 향상시켜주는 것이 존재하는데 InnoDB는 doublewrite buffer라고 불리는 파일 플러쉬 기술이 존재한다 (여러 개의 dirty page를 각각의 데이터파일에 플러쉬하려면 랜덤I/O가 발생하여 시간이 오래 걸리므로 해당 dirty page를 시스템 테이블스페이스 내 하나의 연속적인 extent에 때려넣음으로써 단일 I/O로 저장하는 방법, 이렇게 저장이 되면 정상적인 플러쉬 과정을 한다.) innodb_doublewrite파라미터는 기본적으로 ON인데 서버 crash나 정전 등으로 인한 사고에서 더 안전하게 복구할 수 있도록 해준다. 또한 대부분의 unix 장비에서 fsync() 시스템 콜의 요청을 줄여줌으로써 성능도 향상시키게 된다. 따라서 innodb_doublewrite 옵션을 활성화된 상태로 놔둘 것을 권고하는 바이다.
Specifying the Location and Size for InnoDB Tablespace Files
InnoDB의 테이블스페이스 파일을 셋업하려면 [mysqld] 세션에서 innodb_data_file_path 파라미터를 수정해라. 이 파라미터에는 하나 이상의 데이터 파일에 대한 리스트가 있어야 하며 세미콜론(;)으로 구분해주면 된다.
innodb_data_file_path=datafile_spec1[;datafile_spec2]...
예를 들어 아래와 같이 작성하면 된다.
[mysqld] innodb_data_file_path=ibdata1:12M:autoextend
이것은 자동 증가하는 ibdata1 라는 하나의 12MB짜리 파일을 명시하는 것이다.위치에 대한 내용이 없으므로 자동으로 데이터 디렉토리에 생서하게 된다. 자동 증가하는 50M짜리의 두 개의 데이터 파일을 명시하려면 아래와 같이 쓰면 된다.
[mysqld] innodb_data_file_path=ibdata1:50M;ibdata2:50M:autoextend
만약 자동증가 옵션을 명시했다면 InnoDB는 테이블스페이스가 꽉 차면 자동으로 증가시키며 한번에 8MB씩 증가시킨다. (MariaDB에서는 64로 정의되어 있음) 만약 이 값을 수정하려면 innodb_autoextend_increment 파라미터를 수정하면 된다.
InnoDB는 파일시스템 내 최대 파일 사이즈를 알지 못한다. 따라서 파일시스템 내 최대 파일의 사이즈가 적당히 작은지 잘 모니터링 해야 한다. 자동 증가하는 데이터 파일의 최대 사이즈를 지정하기 위해서는 autoextend 속성 다음에 max 속성으로 지정할 수 있다. max 속성은 데이터 사용량이 매우 중요한 이유가 있는 경우에만 사용해라. 아래 예제는 ibdata1이 최대 500MB까지만 커질 수 있도록 제한을 두는 예제이다.
[mysqld] innodb_data_file_path=ibdata1:12M:autoextend:max:500M
그리고 위치를 지정하려면 innodb_data_home_dir 파라미터를 작성해라. 아래 예제는 /ibdata 아래에 데이터파일을 생성하는 예제이다.
[mysqld] innodb_data_home_dir = /ibdata innodb_data_file_path=ibdata1:50M;ibdata2:50M:autoextend
Note
InnoDB는 디렉토리를 만들지 않기 때문에 /ibdata 디렉토리가 존재하는지 미리 확인해라. 이것은 로그 파일을 지정할 때도 마찬가지이다. 그리고 mysql이 해당 디렉토리에 적당한 권한이 있는지 잘 확인해라.
innodb_data_home_dir 파라미터를 빈 칸으로 놔두고 innodb_data_file_path 파라미터에서 데이터 파일을 절대 경로로 표시할 수 있다.
[mysqld] innodb_data_home_dir = innodb_data_file_path=/ibdata/ibdata1:50M;/ibdata/ibdata2:50M:autoextend
어떤 파일시스템에서는 데이터 파일의 크기가 2G보다 작아야 한다는 것을 명심해라.
14.4.3.1 Configuring InnoDB Buffer Pool Prefetching (Read-Ahead)
read-ahead 요청이란 페이지들이 곧 사용될 것이란 예측을 하고 비동기적으로 여러 개의 페이지를 버퍼 풀로 미리 올려놓는 것을 의미한다. 즉 하나의 익스텐트에 있는 모든 페이지를 한꺼번에 올려놓는 것이다. InnoDB는 I/O 성능을 향상시키기 위해 두 개의 read-ahead 알고리즘을 갖고 있다.
- Linear: 버퍼 풀에서 순차적으로 접근하는 페이지를 보고 어떤 페이지가 곧 사용될 것인지를 판단하는 기법이다. 언제 read-ahead 가 작동될 것인지는 얼마나 많은 연속적인 페이지가 접근되는지를 기준으로 삼으며 innodb_read_ahead_threshold 파라미터로 조절할 수 있다. 이 파라미터가 있기 전에는 현 익스텐트의 마지막 파이지를 읽으면서 다음 익스텐트 전체를 미리 꺼내야 하는지만을 계산했었다.innodb_read_ahead_threshold 파라미터는 InnoDB가 순차적인 페이지 접근 패턴에 대해 얼마나 민감한지를 결정한다. 만약 이 파라미터에 정의된 값보다 더 많은 수의 순차적 페이지 접근이 발생한다면 InnoDB는 비동기 read-ahead 를 동작시켜 전체 익스텐트를 가져온다. 파라미터의 값은 0~64까지 올 수 있ㅇ며 기본 값은 56이다. 이 값을 더 높이면 그만큼 접근 패턴에 대해 엄격하다는 뜻이다. 에를 들어 이 값은 48개로 낮추면 현 익스텐트에서 48개의 page만큼만 순차적 접근이 발생하면 linear read-ahead를 동작시킨다.
- Random: read-ahead 는 이미 버퍼 풀에 있는 페이지에 대해 페이지가 읽히는 순서에 상관없이 언제 페이지가 필요할 것인지를 예측하는 것이다. 만약 버퍼 풀에서 동일한 익스텐트 내 13개의 연속적인 페이지만 발견되어도 InnoDB는 익스텐트의 남은 페이지에 대해 미리 비동기적으로 가져오는 것이다. 이것을 활성화하려면 innodb_randmon_read_ahead 기능을 ON해라.SHOW ENGINE INNODB STATUS를 보면 read-ahead 알고리즘이 얼마나 효과적인지 확인할 수 있다.
14.4.3.2 Configuring the Rate of InnoDB Buffer Pool Flushing
InnoDB는 어떤 task들은 백그라운드로 동작시킨다. 가령 dirty page를 백그라운드로 내려보내는 것이 있다. InnoDB는 innodb_max_dirty_pages_pct 로 정의한 값보다 버퍼 풀 내에 더티 페이지의 비율이 커지면 플러쉬 시킨다.
InnoDB는 적당한 플러쉬 속도를 측정하는 알고리즘을 갖고 있는데 리두로그 발생량과 현재의 플러쉬 속도를 기반으로 측정한다. 이 방법의 목적은 버퍼 풀의 상태를 클린하게 유지하면서 적당한 플러쉬 속도를 유지하도록 만듦으로써 전반적으로 안정적인 성능을 만드는데에 있다. 플러쉬 속도를 자동적으로 조절하는 것은 과도한 버퍼 풀 플러쉬가 발생하여 정상적인 R/W을 방해하는 갑작스런 사고를 방지하는데 도움이 된다.
InnoDB는 로그파일을 원형 방식으로 사용한다. 로그 파일을 재사용하기 전에 InnoDB는 해당 로그파일이 가지고 있는 리두 엔트리에 대한 부분을 버퍼 풀에서 디스크로 플러쉬시킨다. 이 과정을 sharp 체크포인트라고 한다. 만약 워크로드가 write의 비중이 크다면 많은 로그를 발생시킬 것이며 모두 리두 로그에 쓰이게 될 것이다. 만약 리두 파일의 공간이 모두 사용되면 sharp 체크포인트가 발생하게 되어 가용한 성능이 잠깐 줄어들게 된다. 이 현상은 innodb_max_dirty_pages_pct에 도달하지 않더라도 발생한다.
InnoDB는 이 현상을 회피하기 위해 버퍼 풀 내에 더티 페이지의 비율과 리두 로그의 발생 속도를 측정한 값을 기반으로 휴리스틱 기반의 알고리즘을 사용한다. 이 값들을 가지고 버퍼 풀에서 초당 플러쉬해야 하는 더티 페이지의 개수를 결정한다. 이 자율적응 알고리즘은 워크로드가 급변하는 상황에서도 효과적으로 쓰일 수 있다.
이 알고리즘을 내부적으로 벤치마킹한 결과 성능을 일정하게 잘 유지할 뿐만 아니라 전반적인 성능을 매우 향상시켰다.
적응적 플러쉬 기법은 워크로드의 I/O 패턴에 매우 큰 효과를 미치기 때문에 innodb_adaptive_flushing 파라미터를 통해 이 기법을 비활성화 하는 방법도 존재한다.
14.4.3.3 Making the Buffer Pool Scan Resistant
엄격한 LRU 알고리즘을 사용하기 보다 InnoDB는 버퍼 풀로 로딩되었다가 두 번 다시는 쓰이지 않을 데이터의 양을 최소화하는 기술을 사용하고 있다. 이 기술의 목표는 비록 read-ahead나 full table 스캔으로 인해 어쩌면 재사용하지 않을 수도 있는 페이지라도 가급적 자주 억세스되는 hot 페이지를 선별하는 것이다.
새로 읽히는 블럭은 LRU의 중간에 insert된다. 새로 읽히는 모든 페이지들은 기본적으로 LRU 리스트의 3/8 위치에 insert된다. 버퍼 풀에서 페이지가 처음으로 읽히면 정면 방향(최근 사용된 것들 있는 방향)으로 이동한다. 그러므로 절대 사용되지 않은 페이지는 절대 LRU의 정면 방향으로 이동할 수가 없게 된다. 그리고는 엄격한 LRU 도달에 의해 age out 된다. 이 배열 방법은 LRU 리스트를 두 개의 세그먼트로 나누는데 insert 포인트보다 아래에 있는 페이지들을 old라 간주하고 LRU에서 방출 대상의 희생양으로 삼는다.
InnoDB의 버퍼 풀 작동 방식이나 LRU 알고리즘의 자세한 특성을 알고싶으면 8.10.1의 The InnoDB Buffer Pool 을 참조해라.
LRU list의 insert 포인트를 조절할 수 있는데 테이블 스캔이나 인덱스 스캔에도 동일하게 적용할 것인지도 결정할 수 있다. innodb_old_blocks_pct 파라미터는 old 블럭의 비중을 결정한다. 기본 값은 37로써 3/8에 100을 곱한 값이다. 5부터 95까지 설정할 수 있다. 5로 설정하면 버퍼 풀로 새로 insert된 페이지는 매우 빨리 age out 된다. 95로 설정하면 버퍼 풀의 5% 만이 hot 페이지로 설정되어 일반적인 LRU와 비슷한 구조를 갖게 된다.
read-ahead로 인해 버퍼 풀이 지저분해지는 것을 막아주는 이 최적화 방식 테이블 및 인덱스 스캔 페이지로 버퍼풀이 지저분해지는 것을 방지해주기도 한다. 이런 스캔에서 올라온 데이터 페이지의 경우 대부분 짧은 시간 내에 몇 번 억세스 되고 그 이후로는 접근되지 않는 경우가 많다. innodb_old_blocks_time 파라미터는 처음 페이지가 억세스 되고 ?? 이 파라미터의 기본 값은 1000이며 이 값을 증가시키면 버퍼 풀에서 더 빨리 age out 된다.
innodb_old_blocks_pct 파라미터와 innodb_old_blocks_time 파라미터는 모두 글로벌 변수이고 운영중에 변경할 수 있다.
아래는 이 파라미터들의 효과에 대해 추정하는데 도움을 줄 수 있는 자료이다. show engine innodb status 명령에서 나온 BUFFER POOL AND MEMORY 섹션이다. (MariaDB의 조회한 내용을 가져옴)
Total memory allocated 138412032; in additional pool allocated 0 Total memory allocated by read views 200 Internal hash tables (constant factor + variable factor) Adaptive hash index 2217568 (2213368 + 4200) Page hash 139112 (buffer pool 0 only) Dictionary cache 681082 (554768 + 126314) File system 822512 (812272 + 10240) Lock system 333232 (332872 + 360) Recovery system 0 (0 + 0) Dictionary memory allocated 126314 Buffer pool size 8191 Buffer pool size, bytes 134201344 Free buffers 7901 Database pages 290 Old database pages 0 Modified db pages 0 Percent of dirty pages(LRU & free pages): 0.000 Max dirty pages percent: 75.000 Pending reads 0 Pending writes: LRU 0, flush list 0, single page 0 Pages made young 0, not young 0 0.00 youngs/s, 0.00 non-youngs/s Pages read 186, created 109, written 351 0.00 reads/s, 0.00 creates/s, 0.00 writes/s No buffer pool page gets since the last printout Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s LRU len: 290, unzip_LRU len: 0 I/O sum[0]:cur[0], unzip sum[0]:cur[0]
- Old database page: LRU 리스트의 old에 해당하는 페이지를 의미한다.
- Pages made young, not young: young또는 young하지 않게 된 old 페이지의 총 개수
- youngs/s and non young/s: old 페이지가 young 하게 된 초당 속도와 young하지 않게 된 초당 속도이며 InnoDB 상태를 마지막으로 확인해 본 시점간의 비교를 통해 계산한다.
하드웨어 조건, 데이터, 워크로드의 형태에 따라 이 파라미터가 가져오는 효과의 변동이 매우 크므로 운영 환경에 적용하기 전에 반드시 벤치마크를 통해 이 파라미터 변경이 가져오는 효과를 검증해야 한다.
버퍼 풀에 다 들어올 수도 없을 만큼 큰 규모의 테이블을 스캔할 때는 innodb_old_blocks_pct의 값을 작게 함으로써 한번 읽히고 말 페이지가 버퍼 풀의 비중을 많이 차지하지 않도록 해준다. 예를 들어 이 값을 5로 설정하면 한번 읽히고 말 페이지는 버퍼 풀의 5%만 사용할 수 있게 된다.
메모리에 딱 들어맞는 작은 규모의 테이블을 스캔할 때에는, 페이지를 버퍼 풀로 옮기는데 큰 비용이 들지 않기 때문에 innodb_old_blocks_pct의 값을 그냥 놔두던지 더 높게해도 된다.
innodb_old_blocks_time 파라미터의 효과는 innodb_old_blocks_pct 파라미터의 효과보다 예측하기가 어렵다. 그리고 상대적으로 효과도 미미하고 워크로드의 형태에 따라 효과의 격차도 크다. 따라서 innodb_old_blocks_pct 파라미터로 효과를 거두지 못한 경우에 벤치마크 테스트를 고려해 보아라.
14.4.3.4 Using Multiple Buffer Pool Instances
버퍼 풀이 수 기가 바이트에 해당하는 시스템의 경우 버퍼 풀을 몇 개의 인스턴스로 구분하는 것이 동시성을 향상시킬 수 있다. 캐시된 페이지에 대한 읽기/쓰기 시 분리된 쓰레드를 이용함으로써 경합을 감소시키게 된다. 이 특성은 버퍼 풀의 사이즈가 수 기가 바이트에 해당하는 시스템을 목표로 만들어진 것이다. 멀티플 버퍼 풀 인스턴스는 innodb_buffer_pool_instance 파라미터를 통해 조절할 수 있다.
만약 버퍼 풀의 사이즈가 크면 대부분의 데이터 요청이 메모리 안에서 해결됨으로써 만족하게 될 것이다. 그러나 여러 개의 쓰레드가 버퍼 풀을 한꺼번에 억세스하려고 시도함에 따라 병목구간에 빠지게 될 수도 있다. 멀티플 버퍼 풀을 활성화함으로써 이 경합을 최소화할 수 있는데 버퍼 풀에 저장되거나 read되는 페이지는 해시함수에 의해 버퍼 풀 중 하나에 임의적으로 할당된다. 각각의 버퍼 풀은 free리스트, flush리스트, LRU리스트등 버퍼 풀에 관련된 데이터 구조체들을 각자 관리한다.
멀티플 버퍼 풀을 활성화하려면 innodb_buffer_pool_instance 파라미터를 1에서 64 사이의 값을 주면 된다. 다만 이것이 효과를 발휘하려면 innodb_buffer_pool_size의 값이 1G 이상이 되어야 한다. 지정한 값은 total size로 이것은 각각의 버퍼 풀로 쪼개지게 된다. 최고의 성능을 위해서 각각의 버퍼 풀이 최소 1G 이상이 되도록 innodb_buffer_pool_instance와 innodb_buffer_pool_size 파라미터를 알맞게 명시하도록 하라.
14.4.3.5 Preloading the InnoDB Buffer Pool for Faster Restart
14.4.3.6 Tuning InnoDB Buffer Pool Flushing
innodb_flush_neighbors나 innodb_lru_scan_depth 파라미터는 버퍼 풀 플러쉬 과정을 좀 더 세밀하게 튜닝할 수 있는 방법을 제공해준다. 이 옵션은 주로 write 비율이 높은 워크로드에 큰 도움이 된다. 플러쉬의 속도가 충분치 않아 버퍼 풀에 과도한 메모리 사용율을 초래하거나, 플러쉬 속도고 너무 과도하여 I/O 용량을 모두 소모시키는 일이 발생할 수 있다. 이상적인 셋팅은 워크로드 환경, 데이터의 억세스 패턴, 스토리지 구성에 따라 달려있다 (HDD냐 SSD냐 등)
지속적으로 무거운 워크로드가 발생하는 환경이나 긴 간격으로 워크로드가 변동하는 시스템에서 아래의 파라미터는 플러쉬 방법을 정밀하게 튜닝할 수 있는 방법을 제공해준다.
innodb_adaptive_flushing_lwm
innodb_max_dirty_pages_pct_lwm
innodb_io_capacity_max
innodb_flushing_avg_loops
위의 파라미터들은 innodb_adaptive_flushing 옵션에 의해 사용되는 공식을 구성하는 파라미터이다. 파라미터간 서로를 제한하거나 확장하는 관계를 가진 파라미터는 아래와 같다.
innodb_adaptive_flushing –> innodb_adaptive_flushing_lwm
innodb_io_capacity –> innodb_io_capacity_max
innodb_max_dirty_pages_pct –> innodb_max_dirty_pages_pct_lwm
- InnoDB의 adaptive flushing 메커니즘은 모든 케이스에 대해 잘 작동하진 않는다. 단지 리두 로그가 위험 수준에 도달했을 때 가장 큰 혜택을 준다. innodb_adaptive_flushing_lwm 파라미터는 리두 로그의 사용량에 대한 비율로써 한계값을 지정한다. 만약 리두로그의 사용량이 이 값을 넘어서면 innodb_adaptive_flushing 파라미터를 OFF해도 adaptive flushing 기법이 사용된다.
- 만약 adaptive flushing 기법을 사용해도 충분치 않다면 InnoDB는 innodb_io_capacity 파라미터를 이용하여 좀 더 공격적으로 플러쉬시킨다. innodb_io_capacity_max 파라미터는 비상 상황에서 사용되는 사용할 수 있는 I/O의 한계를 의미한다. 이로써 비상 상황에서도 I/O를 모두 소비하지 않도록 제한을 둘 수 있다.
- InnoDB는 버퍼 풀에서 더티 페이지를 플러쉬 시킴으로써 더티 페이지의 비율이 innodb_max_dirty_pages_pct를 초과하지 않도록 한다. 이 파라미터의 기본 값은 75이다.Note
innodb_max_dirty_pages_pct 파라미터는 플러쉬 활동의 목표치만 제공할 뿐이지 플러쉬 속도에는 영향을 주지 않는다.innodb_max_dirty_pages_pct_lwm 옵션은 더티 페이지가 innodb_max_dirty_pages_pct 비율에 도달하지 않도록 미리미리 flushing 하도록 하는 최소한의 더티 페이지 비율을 의미한다. 기본 값은 0.001이며 0인 경우 미리 플러쉬하지 않는다.
innodb_flushing_avg_loops 파라미터는 InnoDB가 얼마나 많은 구 버전의 플러쉬 상태 계산 캡쳐본을 유지할 지를 결정하는 파라미터이다. 이것은 adaptive flush가 워크로드의 변화에 얼마나 빨리 반응하는지를 결정하는 파라미터이다. 이 값을 높게 설정하면 이전에 계산해놓은 스냅본이 더 오래 유지되므로 adaptive 응답속도가 좀 더 느려진다. 또한 백그라운드와 포그라운드의 양적 피드백 관계를 약화시키게 된다. 따라서 이 파라미터를 높게 잡았을 경우 InnoDB의 리두로그 사용율이 75%에 도달하지 않도록 하고 innodb_max_dirty_pages_pct의 세팅이 워크로드에 적당한 더티 페이지의 비율을 유지하고 있는지 반드시 확인하여야 한다.
innodb_log_file_size 의 값이 크고 리두 로그의 사용율이 75%에 도달하지 않는 일정한 워크로드가 있는 시스템의 경우 반드시innodb_flushing_avg_loops 의 값을 높게 잡아야 한다. 그래서 플러쉬가 가능한 한 부드럽게 일어나도록 해야 한다. 워크로드가 극단적으로 튀는 시스템이나 로그 파일의 크기가 충분치 않은 환경에서는 이 값을 작게 잡아야 한다. 그래야 부하에 따라 플러쉬 속도가 맞춰서 작동되며 리두 로그의 사용율이 75%에 도달하지 않도록 관리하는데 도움이 된다.
14.4.3.7 Configuring InnoDB Buffer Pool Size
버퍼 풀의 사이즈는 startup 시 조절할 수도 있고 운영 중에도 조절할 수도 있다. 이 장에서 설명하는 내용은 두 가지 방법에 모두 해당되는 내용이다.
만약 innodb_buffer_pool_size 파라미터를 통해 버퍼 풀의 사이즈를 줄이면 이 명령은 청크 상태로 동작한다. (MariaDB에는 청크 단위가 없음)
wwarchblog 