MySQL Forums
Forum List  »  MyISAM

Re: large tables, large keycaches
Posted by: Jay Pipes
Date: July 26, 2005 04:36PM

Mike,

Have you considered instead of flushing the tables, instead setting up hot and warm caches, and then manually setting the key_cache_size for that cache to zero, then resetting to a larger number. I haven't done the benchmarking, but imagine that this technique would be faster than a full table flush.

If you provide a little more information about your tables, including how often each is queried, how many rows and what key types are, how fresh or stale the key information becomes after X length of time, etc, then I can suggest possibilties for using unique key caches for the different tables, and/or separating some tables out from your main ones to enable a cold cache for less frequently used blocks.

This way, you could set up a hot cache for the most active data tables, allocating 60-70% of your total key_cache RAM to this cache, a warm cache for the semi-active stuff at 20% of the RAM, and a cold cache of 10% of the RAM, which you could assign tables which rarely get hit.

Until MySQL builds more control over diret flushing of certain blocks tied to a segment or entire table, this might be the best solution to your problems, because it will allow you to prevent the main key_cache from using cache space for index blocks that are rarely used...

Sorry for babbling on...it's been a long day...

Cheers,

Jay Pipes
Community Relations Manager, North America, MySQL Inc.

Got Cluster? http://www.mysql.com/cluster
Personal: http://jpipes.com

Options: ReplyQuote


Subject
Views
Written By
Posted
9156
July 25, 2005 09:12PM
3182
July 26, 2005 08:43AM
3126
July 26, 2005 10:37AM
2986
July 26, 2005 11:49AM
2714
July 26, 2005 02:27PM
Re: large tables, large keycaches
2789
July 26, 2005 04:36PM
2470
July 27, 2005 10:49AM
2492
July 27, 2005 03:52PM
2513
August 02, 2005 08:04PM
2606
July 26, 2005 10:51AM
2453
July 27, 2005 07:48AM
2542
July 28, 2005 01:08PM


Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.