Over the last months I’ve seen lots of customers trying to tune the thread concurrency inside MySQL with the variable thread_concurrency. Our advice is: stop wasting your time, it does nothing on GNU/Linux 🙂
Some of the biggest GNU/Linux distributions includes the variable thread_concurrency in their my.cnf file by default. One example is Debian and its variants. Furthermore the default my.cnf files of MySQL like my-large.cnf, my-innodb-heavy-4G.cnf and so on have the thread_concurrency enabled with a tune advice helping to spread the confusion:
# Try number of CPU's*2 for thread_concurrency
Don’t try it. The problems with thread_concurrency are two:
1- It’s deprecated and removed on 5.6.1
2- It only works on old Solaris versions < 9The idea of thread_concurrency for Solaris is using thr_setconcurrency() function to give a hint to the operating system about the number of threads that we want to run at the same time. If you really want to tune the number of threads that runs concurrently you should read about innodb_thread_concurrency:https://www.percona.com/blog/2011/07/28/how-innodb-contention-may-manifest-itself/
innodb_thread_concurrency places a limit on the number of threads that can be running inside InnoDB. The default value in 5.5 is 0 which means “infinite number of threads” but in some workloads limiting the value can give use some performance benefits. As we always say, set up benchmark tests to identify which tuning parameters provide the most benefit to your workload.
thread_concurrency is causing lot of confusion and there are hundred of MySQL tuning howtos that explain how to tune the variable to get better performance. If you have the variable in your my.cnf don’t panic because it does nothing and you’ve only lost some of your valuable time tuning it.