I would agree with Peter. We do not have anything CPU-bound rather all concurrency and IO. The posture of the servers in question is 90% writes and NO deletes. Reads are filled by memcacxhe with the DB as backup if the cache for a record has expired. Without the key cahces performance is abysimal! In our scenario, having the right indexes (read primary and a unique key only) and memory allocated to each key cache helps concurrency a ton.

It did not work for you but it works in a lot of other cases. CPU bound load does not mean it it bottleneck on the key cache mutex.

Also note there is another solution in the meanwhile. MariaDB has got fix to the key cache splitting this mutex to several hashes. You may want to try that.

This is yet another tuning knob that’s completely useless!

First off, your blog is an AWESOME resource and I want to thank you for it. I have found the intel contained herein of great value.

I just wanted to post and confirm that smart use of multiple key caches for MyISAM tables can *dramatically* increase performance in high write applications where you have very little reads (think master tables). The MySQL documentation is not quite as informative as I think it should be for this feature – they suggest creating 3 key caches without really talking about the flexibility you can have. While the MySQL docuementation appraoch may help some you can definitely squeeze more performance with N key caches as you describe.

We have a very high-write environment that uses MyISAM for a number of reason (too much history to go into). Before tinkering with multiple key caches I was able to only get 6k – 7k QPS (really all writes). This was not utilizing the full capacity of the hardware we were running this particular master on. We took the time to examine and segment the tables that were candidates for giving their own key cache too. Our approach was not one cache per table but one per group of tables that are typically updated together by a single process. We choose this route really for manageability (we have a large warehouse with lots of daily tables). We were able to size key caches easily based on index sizes and we now routinely see 15k-20k QPS now! I have seen it go as high as 40k with the current configuration. The good news is the more ram and processor you can throw at your writes, the further you can segment your key caches. Obviously there will be upper bounds but we haven’t even come close to hammering them yet.

As Peter suggests, take time and look at your operational posture and your index sizes and you will be shocked at how much more you can get out of MyISAM. It does not solve all the locking contention but if you have good table designs for your operational posture MyISAM can fly.

How can we monitor performance of multiple key caches, like for monitoring global key cache we use “show status like ‘key_read%’; ” but how i can see same information for new created key cache.

It is hard to explain all the cases when one or another problem may be affecting you. I try best I can when possible. You are also always welcome to hire us to help you to understand what problem you’re really running into.

thank you very much for all your valuable tips! I did not even think the KeyCache could be a problem.

But I wonder how to find out if I am hit by this problem or not. Does “For CPU bound workload” mean that I should have a look at this if the CPU usage on my database server is high?

Maybe it would make the articles even more useful if they started with “You should look at this if you have this problem: …”.

Best Regards

Thomas B.