MySQL5.6 스레드 풀 튜닝

8.11.6.3 스레드 풀 튜닝

이 섹션에서는 초당 트랜잭션 수 등의 통계를 사용하여 측정 된 최고의 성능을 위해 스레드 풀 시스템 변수 설정에 대한 지침을 제공합니다.

thread_pool_size 는 스레드 풀의 성능을 제어하는 가장 중요한 변수입니다. 그것은 서버 시작시에만 설정할 수 있습니다. 스레드 풀 테스트의 경험은 다음과 같이 표시됩니다.

기본 스토리지 엔진이 InnoDB 인 경우 최적의 thread_pool_size 설정은 16에서 36 사이가 될 가능성이 가장 일반적인 최적의 값은 24-36 경향이 있습니다. 36 개 이상의 설정이 최적 인 상황은 없었습니다. 16 미만의 값이 최적 인 특별한 경우가있을 수도 있습니다.

DBT2과 Sysbench 등의 워크로드의 경우, InnoDB 의 최적 값은 보통 36 정도이다 것 같습니다. 상당히 쓰기가 많은 워크로드에서 최적의 설정은 더 적은 수 있습니다.
기본 스토리지 엔진이 MyISAM 인 경우 thread_pool_size 설정은 상당히 작해야합니다. 4-8의 값에서 최적의 성능을 얻을 수있는 경향이 있습니다. 값을 크게하면 성능에 다소 부정적도 극적인 영향을 미치는 경향은 없습니다.

또 다른 시스템 변수 thread_pool_stall_limit 는 차단 된 문 및 장기 실행 문 처리에 중요합니다. MySQL Server를 차단하는 모든 호출 스레드 풀에보고되는 경우 실행 스레드가 차단 될 때마다 알 수 있습니다. 그러나 이것은 항상 들어 맞지 않을 수 있습니다. 예를 들어, 블록은 스레드 풀 콜백에 의해 instrument되지 않은 코드에서 발생할 수 있습니다. 그런 경우 스레드 풀은 차단 된 것으로 보인다 스레드를 식별 할 수 있습니다. 이것은 thread_pool_stall_limit 시스템 변수를 사용하여 튜닝 할 수있는 길이 인 시간을 사용하여 실행됩니다. 이 매개 변수는 서버가 완전히 차단되는 것은 아닙니다. thread_pool_stall_limit 값은 교착 된 서버의 위험을 방지하기 위해 6 초 제한이 있습니다.

thread_pool_stall_limit 하여 스레드 풀은 장기 실행 문을 처리 할 수 있습니다. 장기 실행 문이 스레드 그룹을 차단하는 것이 허용 된 경우 그룹에 할당 된 다른 모든 연결은 차단되고 장기 실행 문이 완료 될 때까지 실행을 시작할 수 없습니다. 최악의 경우이 작업은 몇 시간 또는 며칠이 걸릴 수도 있습니다.

thread_pool_stall_limit 의 값은 그 값 오랫동안 실행 문이 정체중인 것으로 간주하도록 선택해야합니다. 정체중인 문은 추가 컨텍스트 스위치와 경우에 따라서는 추가 스레드 생성이 필요하기 때문에 대량의 추가 오버 헤드를 생성합니다. 한편, thread_pool_stall_limit 매개 변수를 너무 높게 설정하는 것은 장기 실행 문이 필요 이상으로 오랫동안 수많은 단시간 실행 문을 차단하는 것을 의미합니다. 대기의 값이 짧은 스레드가 더 신속하게 시작할 수 있습니다. 짧은 값은 교착 상태 상황을 피하기에 더 적합합니다. 긴 대기 값은 장기 실행 문을 포함하는 워크로드에 유용 현재 문 실행시 다수의 새로운 문을 시작하지 않도록합니다.

서버에 부하가 걸려있는 경우에도 서버는 문 99.9 %가 100 밀리 초 이내에 완료 워크로드를 실행하고 나머지 문이 100 밀리 초에서 2 시간 사이에 완전히 고르게 분산 밖으로 걸릴 것으로합니다. 이 경우 thread_pool_stall_limit 10 (100 밀리 세컨드를 나타낸다)로 설정하면 유익하다고 생각됩니다. 60 밀리 초 기본값은 주로 매우 간단한 문을 실행하는 서버에 충분하다.

thread_pool_stall_limit 매개 변수는 서버의 워크로드에 적절한 균형을 잡을 수 있도록 런타임에 변경할 수 있습니다. TP_THREAD_GROUP_STATS 테이블이 활성화되어 있다고하면, 다음의 쿼리를 사용하여 실행 된 문 정체 된 부분을 확인할 수 있습니다.

 SELECT SUM (STALLED_QUERIES_EXECUTED) / SUM (QUERIES_EXECUTED)
 FROM information_schema.TP_THREAD_GROUP_STATS;

이 수치는 가능한 한 작게해야합니다. 문의 정체 가능성을 줄이려면, thread_pool_stall_limit 값을 늘립니다.

문이 도착했을 때, 그것은 실제로 실행을 시작하기까지 연기 할 수있는 최대 시간은 어느 정도입니까? 다음 조건에 해당합니다.

우선 순위가 낮은 대기열에 200 문이 담겨 있습니다.
우선 순위가 높은 큐에 10 문이 담겨 있습니다.
thread_pool_prio_kickup_timer 은 10000 (10 초)으로 설정되어 있습니다.
thread_pool_stall_limit 100 (1 초)로 설정되어 있습니다.

최악의 경우 10 개의 우선 순위가 높은 문은 장시간 계속 실행 10 개의 트랜잭션을 나타냅니다. 따라서 최악의 경우 우선 순위가 높은 큐는 항상 실행을 대기하고있는 문이 이미 포함되어 있기 때문에이 큐에 문이 이동되지 않습니다. 10 초 후 새로운 문은 우선 순위가 높은 큐로 이동되는 자격을 얻습니다. 그러나 그것이 이동되기 전에 그 전에 모든 문을 이동해야합니다. 우선 순위가 높은 큐로 이동되는 것은 초당 최대 100 문이기 때문에 이것은 또한 2 초 정도 걸릴 수 있습니다. 문이 우선 순위가 높은 큐에 도달했을 때 많은 장기 실행 문이 그 전에있을 수 있습니다. 최악의 경우 그들 모두가 정체 중입니다 다음 문이 우선 순위가 높은 큐에서 때까지 문마다 1 초 정도 걸립니다. 따라서이 시나리오에서는 새로운 문이 실행을 시작하기까지 222 초 정도 걸립니다.

이 예제에서는 응용 프로그램의 최악의 경우를 보여줍니다. 그 처리 방법은 응용 프로그램에 따라 다릅니다. 애플리케이션의 응답 시간에 대한 요구 사항이 높은 경우 아마도 그 자체로 높은 수준의 사용자를 제한하는 것입니다. 그렇지 않은 경우, 스레드 풀 구성 매개 변수를 사용하여 어떠한 최대 대기 시간을 설정할 수 있습니다.