Comments on: MyISAM Scalability and Innodb, Falcon Benchmarks http://www.mysqlperformanceblog.com/2007/10/12/myisam-scalability-and-innodb-falcon-benchmarks/ Everything about MySQL Performance Sat, 07 Nov 2009 18:35:44 -0800 http://wordpress.org/?v=2.8.4 hourly 1 By: Using Multiple Key Caches for MyISAM Scalability | MySQL Performance Blog http://www.mysqlperformanceblog.com/2007/10/12/myisam-scalability-and-innodb-falcon-benchmarks/comment-page-1/#comment-392182 Using Multiple Key Caches for MyISAM Scalability | MySQL Performance Blog Wed, 26 Nov 2008 08:19:12 +0000 http://www.mysqlperformanceblog.com/2007/10/12/myisam-scalability-and-innodb-falcon-benchmarks/#comment-392182 [...] have written before - MyISAM Does Not Scale, or it does quite well - two main things stopping you is table locks and global mutex on the [...] [...] have written before – MyISAM Does Not Scale, or it does quite well – two main things stopping you is table locks and global mutex on the [...]

]]> By: Gunnar http://www.mysqlperformanceblog.com/2007/10/12/myisam-scalability-and-innodb-falcon-benchmarks/comment-page-1/#comment-391520 Gunnar Tue, 25 Nov 2008 09:16:22 +0000 http://www.mysqlperformanceblog.com/2007/10/12/myisam-scalability-and-innodb-falcon-benchmarks/#comment-391520 @Peter, Thanks for the good article. @Rick, > I wish there would be a fix in 5.1; > I don’t want to have to wait for 6.x and Maria and Falcon. I could be wrong but Peters results do not give me the impression that Maria or Falcon will fix this. @Peter,

Thanks for the good article.

@Rick,
> I wish there would be a fix in 5.1;
> I don’t want to have to wait for 6.x and Maria and Falcon.
I could be wrong but Peters results do not give me the impression that Maria or Falcon will fix this.

]]> By: Rick http://www.mysqlperformanceblog.com/2007/10/12/myisam-scalability-and-innodb-falcon-benchmarks/comment-page-1/#comment-360115 Rick Mon, 06 Oct 2008 23:15:05 +0000 http://www.mysqlperformanceblog.com/2007/10/12/myisam-scalability-and-innodb-falcon-benchmarks/#comment-360115 I have been hearing a lot of anecdotal evidence that multiple cores are either bad or not good. Thanks for the detailed analysis of one case. Here are the three main causes of poor performance in multiple cores: * Query Cache has locking problems. What was the setting for Query Cache? If it was even turned on and not used, then there were a locks there. (Granted, perhaps only 1 per SELECT.) * Key_buffer has locking problems, as you clearly note. * InnoDB has malloc problems -- the MySQL version is less efficient than plain 'ole malloc when you have multiple cores. I wish there would be a fix in 5.1; I don't want to have to wait for 6.x and Maria and Falcon. I have been hearing a lot of anecdotal evidence that multiple cores are either bad or not good. Thanks for the detailed analysis of one case. Here are the three main causes of poor performance in multiple cores:

* Query Cache has locking problems. What was the setting for Query Cache? If it was even turned on and not used, then there were a locks there. (Granted, perhaps only 1 per SELECT.)

* Key_buffer has locking problems, as you clearly note.

* InnoDB has malloc problems — the MySQL version is less efficient than plain ‘ole malloc when you have multiple cores.

I wish there would be a fix in 5.1; I don’t want to have to wait for 6.x and Maria and Falcon.

]]> By: Beware of MyISAM Key Cache mutex contention | MySQL Performance Blog http://www.mysqlperformanceblog.com/2007/10/12/myisam-scalability-and-innodb-falcon-benchmarks/comment-page-1/#comment-344186 Beware of MyISAM Key Cache mutex contention | MySQL Performance Blog Wed, 13 Aug 2008 04:11:50 +0000 http://www.mysqlperformanceblog.com/2007/10/12/myisam-scalability-and-innodb-falcon-benchmarks/#comment-344186 [...] thousands of context switches per second with far less work done than one would hope. As we already discussed MyISAM key cache has serious mutex contention issue as there is global mutex which is held for the [...] [...] thousands of context switches per second with far less work done than one would hope. As we already discussed MyISAM key cache has serious mutex contention issue as there is global mutex which is held for the [...]

]]> By: Morten Olsen http://www.mysqlperformanceblog.com/2007/10/12/myisam-scalability-and-innodb-falcon-benchmarks/comment-page-1/#comment-233065 Morten Olsen Wed, 23 Jan 2008 10:11:32 +0000 http://www.mysqlperformanceblog.com/2007/10/12/myisam-scalability-and-innodb-falcon-benchmarks/#comment-233065 Hi Peter, Thanks for the information. I'm not sure I fully understand the sentence: "As Monty explained us in MySQL 4.1 the change to key cache locking was done so disk IO is not done while lock is held, while lock is still held when key block is copied to processing thread local storage on Key Read Request." Does that mean that the contention doesn't happen when the index is read from disk to the buffer, but rather each time some thread try to read from the buffer? Put another way, does the amount of contention relate more to the status variable Key_read_requests rather than Key_reads? Bests, Morten Hi Peter,

Thanks for the information. I’m not sure I fully understand the sentence:

“As Monty explained us in MySQL 4.1 the change to key cache locking was done so disk IO is not done while lock is held, while lock is still held when key block is copied to processing thread local storage on Key Read Request.”

Does that mean that the contention doesn’t happen when the index is read from disk to the buffer, but rather each time some thread try to read from the buffer? Put another way, does the amount of contention relate more to the status variable Key_read_requests rather than Key_reads?

Bests, Morten

]]> By: Michael http://www.mysqlperformanceblog.com/2007/10/12/myisam-scalability-and-innodb-falcon-benchmarks/comment-page-1/#comment-179120 Michael Sat, 20 Oct 2007 00:01:45 +0000 http://www.mysqlperformanceblog.com/2007/10/12/myisam-scalability-and-innodb-falcon-benchmarks/#comment-179120 Dear Steven, May I ask how you would re-write that same query into two queries, a temp table, and a join? I'd like to see the example. Michael Dear Steven,

May I ask how you would re-write that same query into two queries, a temp table, and a join?

I’d like to see the example.

Michael

]]> By: Steven Roussey http://www.mysqlperformanceblog.com/2007/10/12/myisam-scalability-and-innodb-falcon-benchmarks/comment-page-1/#comment-177739 Steven Roussey Tue, 16 Oct 2007 20:11:32 +0000 http://www.mysqlperformanceblog.com/2007/10/12/myisam-scalability-and-innodb-falcon-benchmarks/#comment-177739 OK, though I would be interested to see if you find any differences if you had your tests run with "LIMIT 18" instead of "LIMIT 1206,18". I find that a high index into a limit plus a join kills all my caches. But then again, I may have blobs on all the tables involved... ! OK, though I would be interested to see if you find any differences if you had your tests run with “LIMIT 18″ instead of “LIMIT 1206,18″. I find that a high index into a limit plus a join kills all my caches. But then again, I may have blobs on all the tables involved… !

]]> By: peter http://www.mysqlperformanceblog.com/2007/10/12/myisam-scalability-and-innodb-falcon-benchmarks/comment-page-1/#comment-177730 peter Tue, 16 Oct 2007 19:55:45 +0000 http://www.mysqlperformanceblog.com/2007/10/12/myisam-scalability-and-innodb-falcon-benchmarks/#comment-177730 Steven, The question in this case not the query optimization - we simply took query (a bit obfuscating) from users application and checked how well different storage engines can run it. But note in this case there is no blobs so both Innodb and MyISAM will need to read full rows. Innodb has advantage doing join via primary key but this is other story. Steven,

The question in this case not the query optimization – we simply took query (a bit obfuscating) from users application and checked how well different storage engines can run it.

But note in this case there is no blobs so both Innodb and MyISAM will need to read full rows. Innodb has advantage doing join via primary key but this is other story.

]]> By: Steven Roussey http://www.mysqlperformanceblog.com/2007/10/12/myisam-scalability-and-innodb-falcon-benchmarks/comment-page-1/#comment-177613 Steven Roussey Mon, 15 Oct 2007 21:55:07 +0000 http://www.mysqlperformanceblog.com/2007/10/12/myisam-scalability-and-innodb-falcon-benchmarks/#comment-177613 Monty, not Money! Heh... oops. Monty, not Money! Heh… oops.

]]> By: Steven Roussey http://www.mysqlperformanceblog.com/2007/10/12/myisam-scalability-and-innodb-falcon-benchmarks/comment-page-1/#comment-177612 Steven Roussey Mon, 15 Oct 2007 21:54:41 +0000 http://www.mysqlperformanceblog.com/2007/10/12/myisam-scalability-and-innodb-falcon-benchmarks/#comment-177612 Unlike InnoDb, MyISAM loads up the entire row because it may need 'name'. This is a problem when you have that 'LIMIT 1206,18'. That first number is too high. You will see far greater performance when you break it into two queries -- create a temp table then join. All that (unused) data will ruin the caches. I had a discussion about this with Money back in the 4.0 days. It is just not important enough since they don't expect people to use high limits like that. And there is the temp table workaround. Might be able to use subselects to avoid the huge data load as well. In my case there were big blobs that got loaded up though they weren't needed. Unlike InnoDb, MyISAM loads up the entire row because it may need ‘name’. This is a problem when you have that ‘LIMIT 1206,18′. That first number is too high. You will see far greater performance when you break it into two queries — create a temp table then join. All that (unused) data will ruin the caches. I had a discussion about this with Money back in the 4.0 days. It is just not important enough since they don’t expect people to use high limits like that. And there is the temp table workaround. Might be able to use subselects to avoid the huge data load as well. In my case there were big blobs that got loaded up though they weren’t needed.

]]>