Comments on: A growing trend: InnoDB mutex contention http://www.xaprb.com/blog/2010/03/04/a-growing-trend-innodb-mutex-contention/ Stay curious! Thu, 09 Feb 2012 09:56:43 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Rob Wultsch http://www.xaprb.com/blog/2010/03/04/a-growing-trend-innodb-mutex-contention/#comment-18020 Rob Wultsch Sat, 13 Mar 2010 17:09:46 +0000 http://www.xaprb.com/blog/?p=1674#comment-18020 Baron, for that workload I was looking for peak throughput as you defined it rather than peak responsiveness. Using the 5.1.41 with the innodb plugin I saw a couple interesting things: I observed a double peak in terms of peak throughput with the greater maxima by a hair happening at low sql and innodb concurrency and another maxima at high sql and innodb concurrency. Throughput was not dramatically reduced with very high sql and innodb concurrency unlike the 4.X series. Throughput was significantly lower with very low sql or innodb concurrency. I think that I was probably hitting a corner case with the workload. I am looking forward to benchmarking several other workloads in the somewhat near future. I am also fairly green when it comes to performing large sets of benchmarks so perhaps I botched the test. From my (limited) testing it looks to me like you are correct that innodb_thread_concurrency is no longer a critical variable, however it seems like it could still be useful when workload is very consistent. mk-query-digest has made it much easier to emulate production workloads. Thank you for a great tool. Baron, for that workload I was looking for peak throughput as you defined it rather than peak responsiveness.

Using the 5.1.41 with the innodb plugin I saw a couple interesting things:
I observed a double peak in terms of peak throughput with the greater maxima by a hair happening at low sql and innodb concurrency and another maxima at high sql and innodb concurrency.
Throughput was not dramatically reduced with very high sql and innodb concurrency unlike the 4.X series.
Throughput was significantly lower with very low sql or innodb concurrency.

I think that I was probably hitting a corner case with the workload. I am looking forward to benchmarking several other workloads in the somewhat near future. I am also fairly green when it comes to performing large sets of benchmarks so perhaps I botched the test.

From my (limited) testing it looks to me like you are correct that innodb_thread_concurrency is no longer a critical variable, however it seems like it could still be useful when workload is very consistent.

mk-query-digest has made it much easier to emulate production workloads. Thank you for a great tool.

]]> By: Xaprb http://www.xaprb.com/blog/2010/03/04/a-growing-trend-innodb-mutex-contention/#comment-18019 Xaprb Sat, 13 Mar 2010 14:41:44 +0000 http://www.xaprb.com/blog/?p=1674#comment-18019 Rob, how do you define performance? That should not be the case for this specific benchmark: latest XtraDB, 32 cores (for example), and "performance" is defined as the sum of the throughput of all threads. I consider innodb_thread_concurrency a vestigial tail of the "built-in InnoDB" that ships by default with MySQL 5.0 or 5.1, and should generally be set to 0 with recent versions of XtraDB or the InnoDB Plugin. Rob, how do you define performance? That should not be the case for this specific benchmark: latest XtraDB, 32 cores (for example), and “performance” is defined as the sum of the throughput of all threads.

I consider innodb_thread_concurrency a vestigial tail of the “built-in InnoDB” that ships by default with MySQL 5.0 or 5.1, and should generally be set to 0 with recent versions of XtraDB or the InnoDB Plugin.

]]> By: Rob Wultsch http://www.xaprb.com/blog/2010/03/04/a-growing-trend-innodb-mutex-contention/#comment-18016 Rob Wultsch Fri, 12 Mar 2010 21:28:51 +0000 http://www.xaprb.com/blog/?p=1674#comment-18016 In general, how often is part of the solution reducing innodb_thread_concurrency? Recently I did a bunch of benchmarks on a cpu bound workload on a box with a bunch of cores. Across all version performance was optimal with innodb_thread_concurrency in the neighborhood of 3. This left me feeling sad. Some of the query pileup issues I have come across appear to be able to be resolved or reduced by reducing innodb_thread_concurrency. Any thoughts? In general, how often is part of the solution reducing innodb_thread_concurrency?

Recently I did a bunch of benchmarks on a cpu bound workload on a box with a bunch of cores. Across all version performance was optimal with innodb_thread_concurrency in the neighborhood of 3. This left me feeling sad.

Some of the query pileup issues I have come across appear to be able to be resolved or reduced by reducing innodb_thread_concurrency. Any thoughts?

]]> By: Xaprb http://www.xaprb.com/blog/2010/03/04/a-growing-trend-innodb-mutex-contention/#comment-17962 Xaprb Mon, 08 Mar 2010 12:17:10 +0000 http://www.xaprb.com/blog/?p=1674#comment-17962 Actually, hardware improvements, including faster disks, will "change the contention." They'll make it worse. They already are. That's my point. Actually, hardware improvements, including faster disks, will “change the contention.” They’ll make it worse. They already are. That’s my point.

]]> By: jametong http://www.xaprb.com/blog/2010/03/04/a-growing-trend-innodb-mutex-contention/#comment-17951 jametong Fri, 05 Mar 2010 05:36:28 +0000 http://www.xaprb.com/blog/?p=1674#comment-17951 yes. Disk seek speed will not change the contention in the db or any other subsystems. yes. Disk seek speed will not change the contention in the db or any other subsystems.

]]>