어떤 함수와 인자값을 전달해서 백그라운드에서 처리되도록 하려면 스레드를 사용해서 작업할 수 있다. 스레드를 사용하면 동시에 여러 개의 작업을 진행시키는 것도 가능하다. 문제는 데이터가 단시간에 다량으로 들어오는 경우인데, 여러 스레드가 동시에 돌아가는 경우 실질적으로는 모두 동시에 돌아가는 것이 아니라 CPU가 “매우 빠른 속도로” 각 스레드 사이의 작업을 전환해가면서 처리하게 된다. 따라서 스레드가 너무 많아지게 되면 스레드 사이의 스위칭에 많은 비용이 들어갈 뿐만 아니라 프로세스 자체가 불안정하게 된다.
한정된 스레드 개수만 사용하여 더 많은 데이터를 다루기 위해서는 스레드 풀이라고도 불리는 작업 큐를 사용하는 방법이 있다. 기본적인 아이디어는 데몬 구현을 설명한 포스트에서 썼던 방법과 비슷하다.…
introduction of the ThreadPuddle#perform method which is a synchronous version of ThreadPuddle#submit which is useful for in situations where you have a concurrent application but need to limit the concurrency of a certain type of action and sill require a result from that action.
MariaDB-5.5.21-beta is the first MariaDB release featuring the new thread pool. Oracle offers a commercial thread pool plugin for MySQL Enterprise, but now MariaDB brings a thread pool implementation to the community!
If you are not familiar with the term, please read the Knowledge Base article about it.
The main design goal of the thread pool is to increase the scalability of the MariaDB server with many concurrent connections. In order to test and demonstrate this, I have run the sysbench OLTP RO benchmark with up to 4096 threads to compare the new pool-of-threads and the traditional thread-per-connection scheduler:
Benchmark description:
sysbench multi table OLTP, readonly
16 tables, totaling 40 mio rows (~10G of data)
16G buffer pool – result is independent of disk performance
mysqld bound to 16 cpu cores, sysbench to the other 8
Read/write OLTP benchmark results will be published as soon as they are available.
Raw benchmark results and the scripts used can be downloaded here
More:
MariaDB versus MySQL - Features: http://kb.askmonty.org/en/mariadb-versus-mysql-features
MariaDB versus MySQL - Compatibility: http://kb.askmonty.org/en/mariadb-versus-mysql
Thread pool in MariaDB 5.5: http://kb.askmonty.org/en/thread-pool-in-mariadb-55