데브러너 (DevRunner)

17.8.9 Purge Configuration

InnoDB는 SQL 구문으로 행을 삭제하더라도 데이터베이스에서 해당 행을 즉시 물리적으로 제거하지 않습니다. 행과 그 인덱스 레코드는, 삭제 작업을 위해 기록된 undo 로그 레코드를 InnoDB가 폐기(discard)할 때만 물리적으로 제거됩니다. 이 제거 작업은, 해당 행이 더 이상 다중 버전 동시성 제어(MVCC)나 롤백을 위해 필요하지 않을 때에만 발생하며, purge라고 부릅니다.

Purge는 주기적인 스케줄에 따라 실행됩니다. Purge는 history list에서 undo 로그 페이지를 파싱하고 처리합니다. History list는 InnoDB 트랜잭션 시스템에 의해 유지되는, 커밋된 트랜잭션에 대한 undo 로그 페이지들의 목록입니다. Purge는 처리한 후 history list에서 undo 로그 페이지들을 해제합니다.

Configuring Purge Threads

Purge 작업은 하나 이상의 purge 스레드가 백그라운드에서 수행합니다. Purge 스레드의 개수는 innodb_purge_threads 변수로 제어됩니다. 사용 가능한 논리 프로세서 수가 <= 16이면 기본값은 1이며, 그렇지 않으면 기본값은 4입니다.

DML 작업이 하나의 테이블에 집중된 경우, 해당 테이블에 대한 purge 작업은 단일 purge 스레드에 의해 수행되며, 이로 인해 purge 작업이 느려지고 purge lag가 증가하며, DML 작업에 대용량 객체 값이 포함되어 있다면 테이블스페이스 파일 크기가 증가할 수 있습니다. innodb_max_purge_lag 설정 값이 초과되면, purge 작업은 사용 가능한 purge 스레드들 사이에 자동으로 재분배됩니다. 이러한 시나리오에서 활성 purge 스레드가 너무 많으면 사용자 스레드와의 경합을 유발할 수 있으므로, innodb_purge_threads 설정을 적절히 관리해야 합니다. innodb_max_purge_lag 변수는 기본적으로 0으로 설정되어 있으며, 이는 기본적으로 최대 purge lag가 없음을 의미합니다.

DML 작업이 소수의 테이블에 집중된 경우, 바쁜 테이블에 대한 접근을 위해 스레드들끼리 서로 경합이 발생하지 않도록 innodb_purge_threads 설정을 낮게 유지하십시오. DML 작업이 많은 테이블에 분산되어 있다면, 더 높은 innodb_purge_threads 설정을 고려하십시오. Purge 스레드의 최대 개수는 32입니다.

innodb_purge_threads 설정은 허용되는 purge 스레드의 최대 개수입니다. Purge 시스템은 사용되는 purge 스레드의 개수를 자동으로 조정합니다.

Configuring Purge Batch Size

innodb_purge_batch_size 변수는 purge가 history list에서 한 번에 하나의 배치로 파싱하고 처리하는 undo 로그 페이지의 개수를 정의합니다. 기본값은 300입니다. 멀티스레드 purge 구성에서 조정자(coordinator) purge 스레드는 innodb_purge_batch_size를 innodb_purge_threads로 나누고, 그 페이지 수를 각 purge 스레드에 할당합니다.

Purge 시스템은 더 이상 필요하지 않은 undo 로그 페이지도 해제합니다. 이 작업은 undo 로그를 128번 반복(iteration)하여 처리할 때마다 수행됩니다. 배치에서 파싱하고 처리하는 undo 로그 페이지의 개수를 정의하는 것 외에도, innodb_purge_batch_size 변수는 undo 로그를 128번 반복(iteration)하는 동안 purge가 해제하는 undo 로그 페이지의 개수도 정의합니다.

innodb_purge_batch_size 변수는 고급 성능 튜닝 및 실험을 위한 것입니다. 대부분의 사용자는 기본값에서 innodb_purge_batch_size를 변경할 필요가 없습니다.

Configuring the Maximum Purge Lag

innodb_max_purge_lag 변수는 원하는 최대 purge lag를 정의합니다. Purge lag가 innodb_max_purge_lag 임계값을 초과하면, purge 작업이 따라잡을 시간을 주기 위해 INSERT, UPDATE, 및 DELETE 작업에 지연(delay)이 부과됩니다. 기본값은 0이며, 이는 최대 purge lag도 없고 지연도 없음을 의미합니다.

InnoDB 트랜잭션 시스템은 UPDATE 또는 DELETE 작업에 의해 인덱스 레코드가 삭제 마크(delete-mark)된 트랜잭션 목록을 유지합니다. 이 목록의 길이가 purge lag입니다.

Purge lag에 대한 지연은 다음 공식에 의해 계산됩니다:

1(purge_lag/innodb_max_purge_lag - 0.9995) * 10000

지연은 purge 배치의 시작 시점에 계산됩니다.

문제가 있는 워크로드에 대한 전형적인 innodb_max_purge_lag 설정 값은 1000000 (100만)일 수 있으며, 트랜잭션이 작아서 크기가 100 byte에 불과하고, purge되지 않은 테이블 행이 100MB까지 허용 가능한 경우를 가정합니다.

Purge lag는 SHOW ENGINE INNODB STATUS 출력의 TRANSACTIONS 섹션에 있는 History list length 값으로 표시됩니다.

1mysql> SHOW ENGINE INNODB STATUS;
2...
3------------
4TRANSACTIONS
5------------
6Trx id counter 0 290328385
7Purge done for trx's n:o < 0 290315608 undo n:o < 0 17
8History list length 20

History list length는 일반적으로 낮은 값이며, 보통 수천 미만입니다. 하지만 쓰기 중심 워크로드나 장기 실행 트랜잭션은, 읽기 전용 트랜잭션에 대해서도 이 값이 증가하도록 만들 수 있습니다. 장기 실행 트랜잭션이 History list length를 증가시킬 수 있는 이유는, REPEATABLE READ와 같은 일관 읽기 트랜잭션 격리 수준에서는, 트랜잭션이 해당 트랜잭션에 대한 읽기 뷰가 생성되었을 때와 동일한 결과를 반환해야 하기 때문입니다. 따라서 InnoDB 다중 버전 동시성 제어(MVCC) 시스템은, 그 데이터에 의존하는 모든 트랜잭션이 완료될 때까지 undo 로그에 데이터의 복사본을 유지해야 합니다. 다음은 History list length를 증가시킬 수 있는 장기 실행 트랜잭션의 예시입니다:

상당한 양의 동시 DML이 발생하는 동안, --single-transaction 옵션을 사용하는 mysqldump 작업.
autocommit을 비활성화한 후 SELECT 쿼리를 실행하고, 명시적인 COMMIT 또는 ROLLBACK을 실행하는 것을 잊는 경우.

Purge lag가 매우 커지는 극단적인 상황에서 과도한 지연을 방지하기 위해, innodb_max_purge_lag_delay 변수를 설정하여 지연을 제한할 수 있습니다. innodb_max_purge_lag_delay 변수는 innodb_max_purge_lag 임계값이 초과되었을 때 부과되는 지연에 대한 최대 지연 시간을 마이크로초 단위로 지정합니다. 지정된 innodb_max_purge_lag_delay 값은, innodb_max_purge_lag 공식으로 계산된 지연 기간에 대한 상한(upper limit)입니다.

Purge and Undo Tablespace Truncation

Purge 시스템은 undo 테이블스페이스를 잘라내기(truncate)하는 역할도 합니다. Purge 시스템이 truncate할 undo 테이블스페이스를 찾는 빈도를 제어하려면 innodb_purge_rseg_truncate_frequency 변수를 설정할 수 있습니다. 자세한 내용은 Truncating Undo Tablespaces를 참조하십시오.