consider reducing the mutex contention in the worker thread pool · tikv/tikv#2586

(2 comments) (0 reactions) (0 assignees)Rust (15,922 stars) (2,189 forks)batch import

component/performancehelp wanted

説明

I find that our worker thread pool uses the traditional mutex + condition var mechanism for the thread interaction.

The task queue is also handled in the mutex, this may cause the frequent lock contention even the task queue has enough tasks and the worker doesn't need to wait.

I abstract the queue from the mutex and use a spinlock to lock separately, do some benchmarks and find the performance increased, see:

./origin_thread_pool
Using 8 threads
204678 QPS
185131 QPS
186840 QPS
165325 QPS

./spin_thread_pool 8
Using 8 threads
232116 QPS
244754 QPS
216727 QPS
235721 QPS

So I think it is worth to re-improve the worker thread pool.

The benchmark cases:

Origin: https://gist.github.com/siddontang/fa81a59e7234e9960f8514785af69e1e Spinlock: https://gist.github.com/siddontang/5b4b023475a55e0d4898117790a224c9

/cc @BusyJay @zhangjinpeng1987 @wentaoxu

コントリビューターガイド

技術スタック: rust
領域: backenddatabaseperformance
Issue 種別: performance
難度: 4
推定時間: half day
活動状況: stale
明確さ: mostly clear
前提条件: Rust programmingconcurrency basicsmutex and spinlock concepts
初心者向け度: 40
調査方針: The issue proposes reducing mutex contention in the worker thread pool by separating the task queue lock from the condition variable mutex, using a spinlock for the queue. The provided benchmarks show performance gains. To implement, examine the current thread pool implementation in TiKV, likely in src/server or a similar directory. Evaluate the existing mutex usage and refactor to introduce a separate spinlock for the task queue, ensuring thread safety. Then benchmark using the provided test cases to verify improvement.