스레드 캐시, Connection Pool, Thread Pool

1. 스레드 캐시(MySQL community Version)

MySQL 서버에서는 연결 스레드 할당으로 인한 리소스 낭비 및 성능 저하를 막기 위해 특정 개수의 스레드를 메모리에 캐싱해서 사용한다. 

이를 통해 연결로 발생하는 오버헤드를 줄일 수 있으며, 클라이언트 커넥션 요청과 (포그라운드)스레드가 1:1로 매핑된다.

즉, 커넥션을 맺은 스레드가 하나의 커넥션 처리만 담당하는게 핵심이다.

 

 

2. Connection Pool

The MySQL Connection Pool operates on the client side to ensure that a MySQL client does not constantly connect to and disconnect from the MySQL server. It is designed to cache idle connections in the MySQL client for use by other users as they are needed. This minimizes the overhead and expense of establishing and tearing down connections as queries are submitted to the MySQL server. The MySQL Connection Pool has no visibility as to the query handling capabilities or load of the back-end MySQL server. By contrast, the Thread Pool operates on the MySQL server side and is designed to manage the execution of inbound concurrent connections and queries as they are received from the client connections accessing the back-end MySQL database. Because of the separation of duties, the MySQL Connection Pool and Thread Pool are orthogonal and can be used independent of each other.

클라이언트 측에서 작동하며, MySQL 클라이언트(Spring Server 등)에서 idle connection을 캐시하여 필요할 때 사용할 수 있도록 설계되었다. MySQL Connection Pool에는 MySQL Server의 쿼리 처리 기능 등이 표시되지 않으며(즉, 커넥션 정보만 관리한다), 이와는 대조적으로 Thread Pool은 connection으로부터 전달되는 query 실행을 관리하도록 설계되었다. 이와 같은 작업 분리를 통해 서로 독립적으로 사용할 수 있다.

요약하면, 기존 (포그라운드)스레드에서 수행했던 연결 관리 + 쿼리 처리 작업 중 연결 관리 부분을 Connection Pool과 Thread Pool로 분리하여 각각 관리하도록 했다는 의미로 생각된다.

 

 

3. Thread Pool (Enterprise 버전, Percona MySQL Server)

클라이언트의 여러 요청을 스레드 풀에서 관리되는 스레드 그룹 내 스레드가 처리할 수 있는 구조이다.

 

각 스레드 그룹에는 그룹에 할당된 connections로부터 들어오는 statement를 수신하는 Listener thread가 있다. statement가 도착하면, 스레드 그룹은 즉시 그 문장을 실행하거나 이후에 실행시키기 위해 queue에 넣는 작업을 수행한다.

• 대기열에 아무것도 없거나, 현재 실행중인 명령문이 없다면 statement가 즉시 실행된다.
• 즉각 실행될 수 없다면, Queuing 된다.

즉각 실행된다면, Listener Thread가 해당 statement를 즉각 수행한다. (이 때 일시적으로 Listner Thread가 없어진다.)

만약 statements가 빠르게 끝난다면, 해당 스레드는 수신 대기 상태(다시 Listening 상태)로 돌아간다. 그렇지 않다면, 스레드 풀에서 해당 statement가 stall되었다고 가정하고 다른 스레드를 새로 start 시킨 후 listening 상태로 돌린다.

이와 같이 스레드 그룹이 stalled statements에 의해 block되지 않도록 스레드 그룹 상태를 정기적으로 모니터링하는 백그라운드 스레드가 존재한다.

 

위에 언급된 것처럼, statement를 즉각 실행한다면 추가 스레드를 만들 필요가 없어진다. 동시 스레드 수가 적을 경우에 가장 효율적인 실행이 보장된다.

 

스레드 풀 생성 시, 그룹 당 하나의 스레드(리스너)와 백그라운드 스레드를 만든다. 추가 스레드는 필요에 따라 생성된다.

 

1) thread_pool_stall_limit

스레드가 정지된 것으로 간주되기까지의 시간을 지정한다. 기본 시간은 60ms이지만 최대 6초까지 설정할 수 있다. 이를 통해 서버 작업량에 적합한 균형을 맞출 수 있도록 구성할 수 있다. 대기 시간이 짧으면 당연히 새로운 스레드가 더 빨리 시작될 것이다.

• 교착 상태를 피하기 위해서는 시간을 짧게 설정한다.
• 너무 많은 새로운 statement를 실행하지 못하도록 하기 위해서는 시간을 길게 설정한다.

 

 

2) high-priority-queue & low-priority-queue

트랜잭션의 첫 번째 statement는 low-priority-queue로 이동한다. 다음 statement는 트랜잭션이 진행 중인 경우(실행이 시작된 경우) high-priority 대기열로 이동하며, 아닐 경우에는 low-priority로 이동한다. thread_pool_high_priority_connection 활성화를 통해 모든 statement가 높은 우선순위로 둘 수 있다.

 

비 트랜잭션 스토리지 엔진을 사용 또는 자동 커밋이 활성화된 경우, 낮은 우선순위 statement로 처리된다. 만약 InnoDB(트랜잭션 엔진), MyISAM(비 트랜잭션)에 대한 명령이 혼합되어 있는 경우, 스레드 풀은 자동 커밋을 활성화하지 않는 한 InnoDB에 대한 명령어를 우선시한다. 자동 커밋 활성화 시 모든 문의 우선순위가 낮다.

 

스레드 그룹이 실행을 위해 대기열에 있는 statement를 선택하면 먼저 높은 우선순위 큐를 찾고 그 다음 낮은 우선순위 큐를 찾는다. statement가 found되면 큐에서 제거 후 바로 실행한다.

 

스레드 그룹이 statement를 실행하기 위해 여러 스레드를 사용할 수 있는 조건은 다음과 같다.

• 하나의 스레드는 statement를 시작하지만 정지된 것으로 간주될 만큼 충분히 오래 실행될 경우, 스레드 그룹은 첫 번째 스레드가 여전히 실행중인 경우에도 다른 스레드가 다른 문을 실행할 수 있도록 허용한다.
• 하나의 스레드가 문을 실행한 다음 block되고 이를 스레드 풀에 report할 경우, 스레드 그룹은 다른 스레드가 다른 문 실행하는 것을 허용한다.

 

스레드 풀의 목적은, 내부적으로 사용자의 요청을 처리하는 스레드 개수를 줄여서 동시 처리되는 요청이 많다 하더라도 MySQL 서버의 CPU가 제한된 개수의 스레드 처리에만 집중할 수 있도록 하여 서버의 자원 소모를 줄이는 것이 관건이다.

앞서 간단히 스레드 풀 기능은 엔터프라이즈 에디션에서만 사용이 가능하다고 했다. 커뮤니티 에디션에서는 Percona Server 플러그인을 추가 설치해서 스레드 풀 기능을 활용할 수 있다.

 

 

참고

---

MySQL :: MySQL 8.0 Reference Manual :: 5.6.3.3 Thread Pool Operation