[MySQL][InnoDB] Buffer Pool 플러싱(Flushing)

■ 버퍼 풀 플러싱 구성

InnoDB는 버퍼 풀에서 더티 페이지 플러시를 포함하여 백그라운드에서 특정 작업을 수행합니다. 더티 페이지란 버퍼풀의 페이지가 수정되었지만 아직 디스크의 데이터 파일에 기록되지 않은 페이지입니다.

 

MySQL 5.7에서는 버퍼 풀 플러싱이 페이지 클리너 스레드에 의해 수행됩니다. 페이지 클리너 스레드 수는 기본값이 4인 innodb_page_cleaners 변수에 의해 제어됩니다. 그러나 페이지 클리너 스레드 수가 버퍼 풀 인스턴스 수를 초과하면 innodb_page_cleaners는 자동으로 innodb_buffer_pool_instances와 동일한 값으로 설정됩니다.

 

더티 페이지의 백분율이 innodb_max_dirty_pages_pct_lwm 변수에 의해 정의 된 낮은 워터 마크 값에 도달하면 버퍼 풀 플러싱이 시작됩니다. 기본 최저 워터 마크는 0이며이 초기 플러싱 동작을 비활성화합니다.

 

innodb_max_dirty_pages_pct_lwm 임계 값의 목적은 버퍼 풀의 더티 페이지 백분율을 제어하고 더티 페이지의 양이 innodb_max_dirty_pages_pct 변수에 의해 정의 된 임계 값에 도달하는 것을 방지하는 것입니다. 참고로 기본 innodb_max_dirty_pages_pct변수의 기본값은 75입니다. 값의 표현은 %를 나타내므로  75%입니다. InnoDB는 버퍼 풀의 더티 페이지 백분율이 innodb_max_dirty_pages_pct 임계 값에 도달 한 경우 버퍼 풀 페이지를 적극적으로 플러시합니다.

 

추가 변수를 사용하면 버퍼 풀 플러싱 동작을 자세하게 조정할 수 있습니다.

+ innodb_flush_neighbors 변수는 버퍼 풀에서 페이지를 플러시 할 때도 다른 더티 페이지를 같은 익스텐트 안에서 플러시할지 여부를 정의합니다.

- 0으로 설정하면 innodb_flush_neighbors가 비활성화됩니다. 같은 익스펜트안의 더티 페이지는 플러시되지 않습니다.

- 기본 설정인 1은 연속된 더티 페이지를 같은 익스텐트 안에서 플러시합니다.

- 2로 설정하면 더티 페이지가 같은 익스펜트 안에서 플러시됩니다.

기존 HDD 저장 장치에 테이블 데이터를 저장하면 한 번의 작업으로 인접 페이지를 플러시하면 다른 시간에 개별 페이지를 플러시하는 것과 비교하여 (디스크 탐색 작업의 경우 주로) I/O 오버 헤드가 줄어 듭니다. SSD에 저장된 테이블 데이터의 경우 검색 시간은 중요한 요소가 아니며 이 설정을 비활성화하여 쓰기 작업을 분산시킬 수 있습니다.

 

+  innodb_lru_scan_depth 변수는 버퍼 풀 인스턴스당 페이지 크리너 스레드가 플러시할 더티 페이지를 찾아 버퍼 풀 LRU 목록에서 얼마나 깊게 검색할지를 지정합니다. 이것은 페이지 클리너 스레드가 초당 한 번씩 수행하는 백그라운드 조작입니다.

기본값보다 작은 설정은 일반적으로 대부분의 작업에 적합합니다. 필요한 것보다 훨씬 높은 값은 성능에 영향을 줄 수 있습니다. 일반적인 워크로드에서 예비 I/O 용량이있는 경우에만 값을 늘려야 합니다. 반대로, 쓰기 집약적인 워크로드가 I/O 용량을 포화시키는 경우, 특히 큰 버퍼 풀의 경우 값을 줄여야 합니다.

innodb_lru_scan_depth를 조정할 때 낮은 값으로 시작하여 사용 가능한 페이지가 거의 없는것을 목표로 설정을 조금씩 높여서 구성합니다. 또한 innodb_lru_scan_depth * innodb_buffer_pool_instances는 초당 페이지 클리너 스레드가 수행하는 작업량을 정의하므로 버퍼 풀 인스턴스 수를 변경할 때 innodb_lru_scan_depth 조정을 고려합니다.

 

innodb_flush_neighbors 및 innodb_lru_scan_depth 변수는 주로 쓰기 집약적인 워크로드를 위한 것입니다. DML활동이 많은 경우 플러시가 충분히 공격적이지 않으면 플러시가 저하되거나 플러시가 너무 공격적인 경우 디스크 쓰기가 I/O 용량을 포화시킬 수 있습니다. 이상적인 설정은 워크로드, 데이터 액세스 패턴 및 스토리지 구성 (예 : 데이터가 HDD 또는 SSD 장치에 저장되어 있는지 여부)에 따라 다릅니다.

 

 

 

▶ 적응적 플러시

InnoDB는 적응형 플러싱 알고리즘을 사용하여 리두 로그 생성 속도와 현재 플러싱 속도에 따라 플러싱 속도를 동적으로 조정합니다. 플러싱 활동이 현재 워크로드와 보조를 맞추도록하여 전반적인 성능을 원활하게 하는 것이 목적입니다. 플러싱 속도를 자동으로 조정하면 버퍼 풀 플러싱으로 인한 I/O 작업 버스트가 일반 읽기 및 쓰기 작업에 사용 가능한 I/O 용량에 영향을 줄 때 발생할 수있는 처리량이 급격히 감소하는 것을 방지 할 수 있습니다.

 

예를 들어 많은 재실행 항목을 생성하는 쓰기 집약적인 워크로드와 관련된것이 분명한 체크 포인트는 예를 들어 처리량을 갑자기 변경시킬 수 있습니다. InnoDB가 로그 파일의 일부를 재사용하려고 할 때 반드시 포인트가 발생합니다. 이렇게하기 전에 로그 파일의 해당 부분에 다시 실행 항목이 있는 더티 페이지가 모두 비워 져야합니다. 로그 파일이 가득 차면 반드시 체크 포인트가 발생하여 처리량이 일시적으로 감소합니다. 이 시나리오는 innodb_max_dirty_pages_pct 임계 값에 도달하지 않은 경우에도 발생할 수 있습니다.

 

적응형 플러싱 알고리즘은 버퍼 풀의 더티 페이지 수와 리두 로그 레코드 생성 속도를 추적하여 이러한 시나리오를 피할 수 있습니다. 이 정보에 따라 초당 버퍼 풀에서 플러시 할 더티 페이지 수를 결정하여 워크로드의 갑작스러운 변경을 관리 할 수 있습니다.

 

innodb_adaptive_flushing_lwm 변수는 리두 로그 용량에 대한 하위 워터마크를 정의합니다. 해당 임계 값을 초과하면 innodb_adaptive_flushing 변수가 비활성화 된 경우에도 적응형 플러싱이 활성화됩니다.

 

내부 벤치마킹에 따르면 알고리즘은 시간이 지남에 따라 처리량을 유지 관리 할뿐만 아니라 전체 처리량을 크게 향상시킬 수 있습니다. 그러나 적응 플러싱은 작업 부하의 I/O 패턴에 큰 영향을 줄 수 있으며 모든 경우에 적합하지 않을 수 있습니다. 리두 로그가 채워질 위험이있을 때 가장 큰 이점을 제공합니다. 적응형 플러싱이 작업 부하의 특성에 적합하지 않은 경우 비활성화 할 수 있습니다. 적응 형 플러싱은 innodb_adaptive_flushing 변수에 의해 제어되며 기본적으로 활성화됩니다.

 

innodb_flushing_avg_loops는 InnoDB가 이전에 계산 된 플러싱 상태 스냅샷을 유지하는 반복 횟수를 정의하여 적응형 플러싱이 포그라운드 워크로드 변경에 얼마나 빨리 응답하는지 제어합니다. innodb_flushing_avg_loops 값이 높으면 InnoDB가 이전에 계산된 스냅샷을 더 오래 유지하므로 적응 플러싱이 더 느리게 응답합니다. 높은 값을 설정하는 경우 리두 로그 활용도가 75 % (비동기 플러시가 시작되는 하드 코딩 된 한계)에 도달하지 않고 innodb_max_dirty_pages_pct 임계 값이 더티 페이지 수를 워크로드에 적합한 레벨로 유지하는 것이 중요합니다. .

 

일관된 워크로드, 큰 로그 파일 크기 (innodb_log_file_size) 및 75 % 로그 공간 사용률에 도달하지 않는 작은 스파이크가있는 시스템은 높은 innodb_flushing_avg_loops 값을 사용하여 가능한 한 매끄럽게 플러시를 유지해야합니다. 많은 공간을 제공하지 않는 극단적 인로드 스파이크 또는 로그 파일이있는 시스템의 경우 값이 작을수록 플러시가 작업 부하 변경을 면밀히 추적하고 75 % 로그 공간 활용에 도달하지 않도록 합니다.

 

플러시가 뒤쳐 질 경우 버퍼 풀 플러시 비율은 innodb_io_capacity 설정에 정의 된대로 InnoDB에서 사용 가능한 I/O 용량을 초과 할 수 있습니다. innodb_io_capacity_max 값은 이러한 상황에서 I/O 용량의 상한을 정의하여 I/O 활동의 급증이 서버의 전체 I/O 용량을 소비하지 않습니다.

 

innodb_io_capacity 설정은 모든 버퍼 풀 인스턴스에 적용 가능합니다. 더티 페이지가 플러시 될 때 I/O 용량은 버퍼 풀 인스턴스간에 동일하게 분배됩니다.

 

※도움이 되셨다면 광고클릭 한번 부탁드립니다.※