Comments on: MySQL QA Team Benchmarks for MySQL 5.1.30 http://www.mysqlperformanceblog.com/2008/12/13/mysql-qa-team-benchmarks-for-mysql-5130/ Everything about MySQL Performance Sat, 21 Nov 2009 05:23:57 -0800 http://wordpress.org/?v=2.8.4 hourly 1 By: peter http://www.mysqlperformanceblog.com/2008/12/13/mysql-qa-team-benchmarks-for-mysql-5130/comment-page-1/#comment-443409 peter Mon, 12 Jan 2009 21:04:54 +0000 http://www.mysqlperformanceblog.com/?p=559#comment-443409 Xan, We did not do 4.1 to 5.1 comparison benchmarks yet. Also note in later 5.0 were considerable parser improvements which made regression from 4.1 less in many cases. Xan, We did not do 4.1 to 5.1 comparison benchmarks yet. Also note in later 5.0 were considerable parser improvements which made regression from 4.1 less in many cases.

]]> By: Xan http://www.mysqlperformanceblog.com/2008/12/13/mysql-qa-team-benchmarks-for-mysql-5130/comment-page-1/#comment-440766 Xan Sat, 10 Jan 2009 07:24:35 +0000 http://www.mysqlperformanceblog.com/?p=559#comment-440766 Do you folks know of any benchmarks that compare 4.1 to 5.1, skipping 5.0? Since 5.0 was 30% slower than 4.1, many high-volume OLTP production environments are still in 4.1. Does a 5.1 speed increase or at least non-decrease over 5.0 really means anything in comparison to 4.1 benchmarks? Do you folks know of any benchmarks that compare 4.1 to 5.1, skipping 5.0? Since 5.0 was 30% slower than 4.1, many high-volume OLTP production environments are still in 4.1. Does a 5.1 speed increase or at least non-decrease over 5.0 really means anything in comparison to 4.1 benchmarks?

]]> By: Morgan Tocker http://www.mysqlperformanceblog.com/2008/12/13/mysql-qa-team-benchmarks-for-mysql-5130/comment-page-1/#comment-413123 Morgan Tocker Mon, 15 Dec 2008 22:42:22 +0000 http://www.mysqlperformanceblog.com/?p=559#comment-413123 Baron - yes, you are correct in my case - and I assume Arjen's as well. Baron – yes, you are correct in my case – and I assume Arjen’s as well.

]]> By: Baron Schwartz http://www.mysqlperformanceblog.com/2008/12/13/mysql-qa-team-benchmarks-for-mysql-5130/comment-page-1/#comment-413122 Baron Schwartz Mon, 15 Dec 2008 22:36:33 +0000 http://www.mysqlperformanceblog.com/?p=559#comment-413122 Arjen, Morgan, (comments #1 and #8) I want to make sure: you are talking about comments that you posted to the Sun blog that didn't get approved, right? You're not talking about comments that you posted here, and got lost? If you posted here and it disappeared, I'll go find them and rescue them. Arjen, Morgan, (comments #1 and #8) I want to make sure: you are talking about comments that you posted to the Sun blog that didn’t get approved, right? You’re not talking about comments that you posted here, and got lost? If you posted here and it disappeared, I’ll go find them and rescue them.

]]> By: Morgan Tocker http://www.mysqlperformanceblog.com/2008/12/13/mysql-qa-team-benchmarks-for-mysql-5130/comment-page-1/#comment-413115 Morgan Tocker Mon, 15 Dec 2008 21:08:23 +0000 http://www.mysqlperformanceblog.com/?p=559#comment-413115 @Arjen, it looks like our comments got moderated to /dev/null. I made a similar comment to what Peter said about the choice of thread concurrency setting on Thursday, and it doesn't appear to have shown up yet: == How does it prove that scalability is improved? Setting InnoDB thread concurrency is a hack that can be used to restrict the amount of work InnoDB is working on internally specifically because it doesn't scale. In your case unrestricting InnoDB seems to be the best option (setting=0) - so the only chart worth looking at is the last one. In which case 5.1 and 5.0 basically score the same. 5.0 is marginally better. Unless I read something incorrectly? == @Arjen, it looks like our comments got moderated to /dev/null.

I made a similar comment to what Peter said about the choice of thread concurrency setting on Thursday, and it doesn’t appear to have shown up yet:

==
How does it prove that scalability is improved?

Setting InnoDB thread concurrency is a hack that can be used to restrict the amount of work InnoDB is working on internally specifically because it doesn’t scale. In your case unrestricting InnoDB seems to be the best option (setting=0) – so the only chart worth looking at is the last one.

In which case 5.1 and 5.0 basically score the same. 5.0 is marginally better.

Unless I read something incorrectly?
==

]]> By: peter http://www.mysqlperformanceblog.com/2008/12/13/mysql-qa-team-benchmarks-for-mysql-5130/comment-page-1/#comment-411928 peter Sun, 14 Dec 2008 19:45:20 +0000 http://www.mysqlperformanceblog.com/?p=559#comment-411928 Erkan, If you get into the thread management they have to be globally managed inside the MySQL process with understanding when thread is really running and when it is not. For example right now the thread is considered "inside innodb kernel" both when it is really using CPU and when it performs disk IO. Not to mention thread gets multiple "tickets" which may keep slot blocked while thread is not really inside Innodb at all - for example storing row in temporary MyISAM table. Finally not all sections are protected by innodb_thread_concurrency - there is also innodb_commit_concurrency on Innodb stage, not to mention contentions on MySQL level which need to be management. Smart Thread Management is really very complex for MySQL and I do not expect it to happen as it would need to have to be done cross storage engines to be really done properly. Thread Pool is one simple way to solve this problem, in particular if you have reasonably short queries. The problem is it does not work for general use right now. Erkan,

If you get into the thread management they have to be globally managed inside the MySQL process with understanding when thread is really running and when it is not. For example right now the thread is considered “inside innodb kernel” both when it is really using CPU and when it performs disk IO. Not to mention thread gets multiple “tickets” which may keep slot blocked while thread is not really inside Innodb at all – for example storing row in temporary MyISAM table. Finally not all sections are protected by innodb_thread_concurrency – there is also innodb_commit_concurrency on Innodb stage, not to mention contentions on MySQL level which need to be management.

Smart Thread Management is really very complex for MySQL and I do not expect it to happen as it would need to have to be done cross storage engines to be really done properly.

Thread Pool is one simple way to solve this problem, in particular if you have reasonably short queries. The problem is it does not work for general use right now.

]]> By: peter http://www.mysqlperformanceblog.com/2008/12/13/mysql-qa-team-benchmarks-for-mysql-5130/comment-page-1/#comment-411925 peter Sun, 14 Dec 2008 19:40:16 +0000 http://www.mysqlperformanceblog.com/?p=559#comment-411925 Mark, This makes me even more curious. Good changes. Bad changes you want to understand them anyway at least to be aware of known side effects :) Mark,

This makes me even more curious. Good changes. Bad changes you want to understand them anyway at least to be aware of known side effects :)

]]> By: Erkan http://www.mysqlperformanceblog.com/2008/12/13/mysql-qa-team-benchmarks-for-mysql-5130/comment-page-1/#comment-411913 Erkan Sun, 14 Dec 2008 18:43:32 +0000 http://www.mysqlperformanceblog.com/?p=559#comment-411913 Peter, on which different level? Im used to tune innodb_thread_concurrency. I fact it would be great if I could get rid of this kind of "tuning". It sucks:-) So when you say it *was* limited Im wouldnt bother with it anymore *yippi*. Would you say innodb_thread_concurrency is some kind of deprecated? Peter,
on which different level?
Im used to tune innodb_thread_concurrency. I fact it would be great if I could get rid of this kind of “tuning”. It sucks:-)
So when you say it *was* limited Im wouldnt bother with it anymore *yippi*.
Would you say innodb_thread_concurrency is some kind of deprecated?

]]> By: Mark Callaghan http://www.mysqlperformanceblog.com/2008/12/13/mysql-qa-team-benchmarks-for-mysql-5130/comment-page-1/#comment-411893 Mark Callaghan Sun, 14 Dec 2008 18:01:40 +0000 http://www.mysqlperformanceblog.com/?p=559#comment-411893 I compared the code between 5.1.30 and 5.0.72 that handles innodb_thread_concurrency (srv/srv0srv.c). I did not see a difference. It would be nice to know why that has such an impact on the results. I compared the code between 5.1.30 and 5.0.72 that handles innodb_thread_concurrency (srv/srv0srv.c). I did not see a difference. It would be nice to know why that has such an impact on the results.

]]> By: peter http://www.mysqlperformanceblog.com/2008/12/13/mysql-qa-team-benchmarks-for-mysql-5130/comment-page-1/#comment-411889 peter Sun, 14 Dec 2008 18:00:19 +0000 http://www.mysqlperformanceblog.com/?p=559#comment-411889 Erkan, Why ? innodb_thread_concurrency=0 suppose to win the game because it is artificial limit which was needed because Innodb's abilities to deal with contention in kernel are low. Plus it was done in a simple way which adds more contention and even more - latency. Thread will sleep for few milliseconds before even starting to wait. Indeed to get the best performance from given amount of cores you want to manage threads carefully, though it is better done on the different level. Erkan,

Why ? innodb_thread_concurrency=0 suppose to win the game because it is artificial limit which was needed because Innodb’s abilities to deal with contention in kernel are low. Plus it was done in a simple way which adds more contention and even more – latency. Thread will sleep for few milliseconds before even starting to wait.

Indeed to get the best performance from given amount of cores you want to manage threads carefully, though it is better done on the different level.

]]>