무거운 InnoDB 워크로드에 맞게 MySQL을 어떻게 조정합니까?

주로 InnoDB 테이블이있는 프로덕션 OLTP 시스템 가정

• 잘못 구성되거나 잘못 구성된 시스템의 일반적인 증상은 무엇입니까?
• 어떤 구성 매개 변수를 기본값에서 가장 일반적으로 변경합니까?
• 문제가 발생하기 전에 어떻게 잠재적 병목 현상을 발견합니까?
• 활성 문제를 어떻게 인식하고 해결합니까?

특정 status변수 및 진단을 자세히 설명하는 모든 일화를 알 수 있습니다.

여기에 썬의 제니 첸에서 InnoDB의 조정에 대한 좋은 기사입니다 - 그녀는 그것의 일부는 솔라리스 고유의 MySQL에 대한 많은 블로그를 (예를 들어, 사용 의 DTrace ) 전체 블로그 재미있는 맛있는 가벼운 음식이 가득하지만.

흥미롭게도 MySQL 5.5에서는 여러 개의 innodb 버퍼 풀을 가질 수 있습니다.

관심있는 매개 변수는

• innodb_buffer_pool_instances (기본값은 1)
• innodb_buffer_pool_size (기본값은 1G)

약 한 달 만에 클라이언트에 112 개의 innodb 버퍼 풀을 구현할 예정입니다. 어떻게되었는지 알려 드리겠습니다.

업데이트 2011-02-27 21:57 EDT

innodb_buffer_pool_instances의 최대 값이 64 144GB로 구성하기로 결정 했으므로 innodb_buffer_pool_instances를 18로 설정하고 innodb_buffer_pool_size를 8로 설정했습니다. 현재 450GB로 서버를로드하고 있습니다.

업데이트 2011-04-28 13:44 EDT

여러 개의 InnoDB 버퍼 풀을 사용해 보았습니다. 스레딩 잠금 및 경합이 너무 많습니다. 단일 162GB 버퍼 풀 + 설정 read_io_threads 및 write_io_threads를 64 (최대 값)로 변경했습니다. 이것은 더 잘 작동했습니다.

업데이트 2012-07-03 17:27 EDT

MySQL에 대해 놀라운 것을 배웠습니다. 물리적 CPU 수로 나눈 총 설치 수 보다 큰 단일 모 놀리 식 InnoDB 버퍼 풀을 할당하면 전체 InnoDB 버퍼 풀로 인해 정기적으로 메모리 스와핑으로 OS가 시작됩니다. innodb_buffer_pool_instances로 알려진 MySQL 5.5의 옵션을 사용하여 버퍼 풀을 분할 할 수 있습니다. 어제 작년에 제가 언급 한 고객을 위해이를 올바르게 구현했습니다. 여전히 클라이언트의 버퍼 풀에 162GB가 있습니다. 각 DB 서버는 이중 헥사 코어이므로 서버의 innodb_buffer_pool_instances 옵션을 2로 설정했습니다. 12로 설정하려고 생각했지만 동료가 제레미 콜 (Jeremy Cole)의 MySQL과 Swappiness 블로그를 보여주었습니다.. 그것을 읽은 후, 나는 그것을 내 고객을 위해 즉시 실천에 넣었습니다. 나는이 명령을 실행

numactl --hardware

192GB의 서버 RAM이 96GB로 각 물리적 코어에 매핑되는 것을 보았습니다. 따라서 innodb_buffer_pool_instances를 2로 설정했습니다. 지금 상황이 좋아 보입니다. 나는 이것이 다음 2 montns의 메모리 스왑에 어떻게 영향을 미치는지 알기 위해 대답을 업데이트 할 것입니다.

다음 자료를 탐색 할 수 있습니다.

• 모범 사례에 대한 FAQ
• 수동 : 서버 매개 변수 튜닝
• 수동 : InnoDB 튜닝
• 중요한 변수 의 오래된 목록 .

먼저 my.cnf에서 기본 InnoDB 버퍼 풀 크기를 늘리십시오 (기본값은 8MB라고 생각합니다)

RAM 크기의 75 %로 설정해야합니다 (일반적으로)

어떤 구성 매개 변수를 기본값에서 가장 일반적으로 변경합니까?

메모리 구성