[AWS RDS MySQL] InnoDB cache warming

-          버퍼풀 정보를 저장하고 시작시 로드하여 워밍업 단계 생략하기

 

l  Version : AWS RDS MySQL 5.6 later

 

InnoDB cache warming(캐시워밍) DB 인스턴스가 종료될 버퍼 풀의 현재 상태를 저장한 다음 DB 인스턴스가 시작될 저장된 버퍼 정보를 다시 로드하여 MySQL DB 인스턴스에 대한 성능 향상을 제공할 있다. 뜻은 정상적인 데이터베이스 사용에서 버퍼풀의 워밍업 필요를 무시하고 대신 알려진 공통 쿼리에 대한 페이지로 버퍼풀을 미리 로드한다. 버퍼풀 정보를 저장하는 파일은 페이지 자체가 아니라 버퍼풀에 있는 페이지에 대한 메타데이터만 저장한다. 따라서 결과적으로 파일에 많은 저장공간이 필요하지 않다. 파일크기는 캐시 크기의 0.2% 정도이다. 예를들어 64GB캐시의 경우 캐시 워밍업 파일은 128MB이다. 캐시워밍에 대한 자세한 내용은 MySQL 공식 문서인 아래 링크에서 확인할 있다.

l  Saving and Restoring the Buffer Pool State : https://dev.mysql.com/doc/refman/8.0/en/innodb-preload-buffer-pool.html

 

AWS RDS에서는 MySQL 5.6 버전 이상에 대해서 InnoDB 캐시 워밍업을 지원한다. InnoDB 캐시 워밍업을 활성화 하려면 DB 인스턴스의 파라미터 그룹에서 innodb_buffer_pool_dump_at_shutdown,  innodb_buffer_pool_load_at_startup 파라미터를 1 설정해야 한다. 해당 파라미터 값을 변경하면 해당 파라미터 그룹을 사용하는 모든 MySQL DB 인스턴스에 영향이 있기 때문의 사용시 주의하도록 한다. 특정 MySQL 대해서만 InnoDB 캐시 워밍업을 활성화 하려면 해당 인스턴스에 대한 파라미터 그룹을 생성 하도록 한다.

 

InnoDB 캐시 워밍은 주로 표준 스토리지를 사용하는 DB 인스턴스에 대한 성능 이점을 제공한다. PIOPS 스토리지를 사용하는 경우 일반적으로 상당한 성능 이점이 나타나지 않는다. InnoDB 캐시 워밍을 활성화 하였더라도 장애 조치중과 같이 MySQL DB 인스턴스가 정상적으로 종료되지 않으면 버퍼풀 상태가 디스크에 저장되지 않는다. 경우 MySQL DB 인스턴스가 다시 시작될 사용 가능한 모든 버퍼 파일을 로드 한다. 이런 경우에도 데이터베이스에는 아무런 이상이 없지만 복원된 버퍼풀은 가장 최근의 상태를 반영하지 않을 수도 있다. 시작 InnoDB 캐시를 워밍업 하는데 사용할 있는 버퍼풀의 최신 상태를 사용하려면 주기적으로 버퍼풀을 덤프하는 것이 좋다.

버퍼풀의 현재 상태를 디스크에 저장하려면 아래 프로시저를 호출 한다.

CALL mysql.rds_innodb_buffer_pool_dump_now();

 

디스크에 저장된 버퍼풀의 상태를 로드하려면 아래 프로시저를 호출 한다.

CALL mysql.rds_innodb_buffer_pool_load_now();

 

진행중인 로드 작업을 취소하려면 아래 프로시저를 호출 한다.

CALL mysql.rds_innodb_buffer_pool_load_abort();

 

버퍼풀을 주기적으로 자동으로 덤프하는 이벤트를 생성하여 사용할 경우 수동으로 매번 호출할 필요가 없다. 아래 스크립트는 매시간 버퍼풀을 덤프하는 periodic_buffer_pool_dump라는 이벤트를 생성한다.

CREATE EVENT periodic_buffer_pool_dump
ON SCHEDULE EVERY 1 HOUR
DO CALL mysql.rds_innodb_buffer_pool_dump_now();

 

 

[참고자료]

l  https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_MySQL.html#MySQL.Concepts.VersionMgmt

l  https://dev.mysql.com/doc/refman/8.0/en/innodb-preload-buffer-pool.html

l  https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mysql_rds_innodb_buffer_pool_dump_now.html

l  https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mysql_rds_innodb_buffer_pool_load_now.html

l  https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mysql_rds_innodb_buffer_pool_load_abort.html

 

 

 

2022-03-17 / Sungwook Kang / http://sungwookkang.com

 

 

AWS RDS, MySQL, InnoDB Cache warming, 캐시워밍업, 버퍼풀, buffer pool

MySQL InnoDB Buffer Pool Resizing Online

 

·       Version : MySQL 5.7.5, 8.0

 

MySQL 5.7.5 부터 InnoDB 버퍼풀의 크기를 서비스 가동중에도 동적으로 조절할 있다. 동적으로 버퍼풀 확대 또는 축소를 제공하기 위해 청크 크기를 정의하는 새로운 변수인 innodb_buffer_pool_chunk_size 도입되었으며, 변수는 동적이 아니며 잘못 구성되면 원하지 않는 상황이 발생할 수도 있다.

아래 그림은 innodb_buffer_pool_size, innodb_buffer_pool_instances , innodb_buffer_pool_chunk_size 상호작용하는 방식을 나타낸것이다.

 

버퍼풀은 여러 인스턴스를 보유할 있으며 인스턴스는 청크로 분할된다. 인스턴스의 수는 1 ~ 64 까지 있으며 청크의 양은 1000개를 초과하지 않도록 해야한다. 따라서 3GB RAM 있는 서버에서, 8개의 인스턴스가 있는 2GB 버퍼 기본값(128M) 청크를 가지고 있는 경우 인스턴스당 2개의 청크를 얻게 된다. 뜻은 16개의 청크가 있음을 의미한다.

 

현재 설정되어있는 버퍼풀 크기를 확인하는 방법은 아래 스크립트를 사용한다.

mysql> show global variables like 'innodb_buffer_pool_size';

+-------------------------+------------+

| Variable_name           | Value      |

+-------------------------+------------+

| innodb_buffer_pool_size | 1073741824 |

+-------------------------+------------+

 

버퍼 크기를 조절하는 방법은 아래 스크립트를 실행한다.  이때 파라메터는 바이트 값이므로 설정시 주의 한다.

mysql> set global innodb_buffer_pool_size=1610612736;

 

 

 

[참고자료]

·       InnoDB Buffer Pool Resizing: Chunk Change : https://www.percona.com/blog/2018/06/19/chunk-change-innodb-buffer-pool-resizing/

 

 

 

 

2020-10-20 / Sungwook Kang / http://sungwookkang.com

 

MySQL, Buffer Pool, innodb_buffer_pool_size, innodb_buffer_pool_instances , innodb_buffer_pool_chunk_size, 버퍼풀 사이즈 조절

SQL Server Page Life Expectancy (PLE)

 

  • Version : SQL Server 2005, 2008, 2008R2, 2012, 2014

 

SQL Server Page Life Expectancy(PLE)는 페이지 참조 없이 데이터가 버퍼 풀에 남아 있는 시간으로 성능 카운터의 SQL Server:Buffer Manager, SQL Server:Buffer Node에서 현재 값을 확인 할 수 있다.

 

  • SQL Server:Buffer Manager / Page life expectancy : 페이지가 참조 없이 버퍼풀에 남아 있는 시간(초)
  • SQL Server:Buffer Node / Page life expectancy : 페이지가 참조 없이 노드에서 버퍼풀에 남아 있는 시간(초).

 

여기에 표시되는 값으로 버퍼풀에 데이터가 머무르는 시간을 확인 할 수 있다. 하지만 여기에서 나타내는 PLE 값이 정말 유용한 정보인지 생각해 보아야 한다. 오늘날의 대부분 시스템들은 NUMA를 사용한다. 그래서 버퍼 풀은 각 NUMA 노드로 분리된 자신의 버퍼풀 목록을 관리한다.

 

Buffer Manager: Page life expectancy카운터는 각 노드의 버퍼풀의 PLE를 추가한 다음 평균을 계산한다. 이 수치는 우리가 생각하는 산술평균보다 값이 낮다. (버퍼 관리자의 비율 평균 : http://en.wikipedia.org/wiki/Harmonic_mean). 이 뜻은 각 NUMA 노드에서 어떤 일이 일어나는지 진정한 의미가 부여 되지 않음을 의미한다.

 

예를 들어 8 NUMA 노드에서 PLE가 4000이면 전반적인 PLE는 4000이다.

4 / (1/(1000 x 4000) + 1/(1000 x 4000) + 1/(1000 x 4000) + 1/(1000 x 4000)) / 1000 = 4000

 

하나의 노드 PLE가 2200으로 떨어지면 전체는 3321이 된다.

4 / (1/(1000 x 2200) + 1/(1000 x 4000) + 1/(1000 x 4000) + 1/(1000 x 4000)) / 1000 = 3321

 

하나의 노드 PLE가 200으로 떨어진다면 전체는 695가 된다.

4 / (1/(1000 x 200) + 1/(1000 x 4000) + 1/(1000 x 4000) + 1/(1000 x 4000)) / 1000 = 695

 

이 수치는 서버가 전반적으로 강한 압력을 받고 있다고 생각되지만 하나의 노드를 제외한 나머지는 아무런 문제가 없다. 따라서 버퍼풀의 압력에 대한 정확한 뷰를 확인하여면 각 노드에서의 PLE를 확인하여 경고에 대한 적절한 임계값을 찾아야 한다.

 

 

[참고자료]

http://www.sqlskills.com/blogs/paul/page-life-expectancy-isnt-what-you-think/

http://blogs.msdn.com/b/psssql/archive/2015/05/14/sql-server-page-life-expectancy-ple.aspx

 

2015-05-20 / 강성욱 / http://sqlmvp.kr

 

Sqlserver, mssqlserver, Page life expectancy, PLE, 버퍼풀, buffer pool, NUMA

+ Recent posts