component/performancedifficulty/hardhelp wanted
Métriques du dépôt
- Stars
- (15 922 stars)
- Métriques de merge PR
- (Merge moyen 28j 9h) (68 PRs mergées en 30 j)
Description
Description
Now we have too many thread pools for read operations in TiKV. It increases the cost of context switches and thread scheduling. If we can unify the thread pools in TiKV, we can improve the performance. However, existing thread pools for common IO use are not suitable for us. Instead of balanced scheduling, we hope different tasks can have different priority and big tasks with lower priority don’t block small tasks. Therefore, we need a thread pool for prioritized tasks.
- Objective: TiKV with the new thread pool should get its peak performance notably improved and not bring side effects (like latency increase or jittering). Meanwhile, we can limit the impact of big tasks or tasks with low priority on small or important tasks.
@waynexia built a thread pool upon juliex as a PoC, showing the max throughput significantly improves (sysbench point_select QPS 39k -> 59k). But it has poor latency performance. Take a look if you're interested: https://github.com/waynexia/texn
Difficulty
- Hard
Score
- 6000
Mentor(s)
- @sticnarf
Recommended Skills
- Concurrent programming
- Scheduling algorithms
- Rust language