ps: forgot to mention this MDEV which is also relevant to the thread (i
think) that i made about backporting the default automatic value of
"table_definition_cache" from MySQL 5.6.8+ (400 + (table_open_cache / 2)
and limited to 2000) instead of a fixed value of 400 :
https://mariadb.atlassian.net/browse/MDEV-7261
Le 22/04/2015 00:31, Jean Weisbuch a écrit :
There was also a MDEV created about this very problem on MariaDB by
Guillaume : https://mariadb.atlassian.net/browse/MDEV-7292
But in my opinion, this specific test is only usefull to see
scalability issues or the cache warming impact but it doesnt really
reflect a typical real-world usage (the original topic here) : if you
use this cache its because you wont always query different tables but
eventually have queries on tables already cached.
I wonder what is the performance difference when the cache is warm and
all tables are already in cache vs. a way too limited table cache that
will have to purge LRU tables frequently.
Le 21/04/2015 23:37, Sergei Golubchik a écrit :
Hi, Justin!
On Apr 21, Justin Swanhart wrote:
It is in fact, negatively scaleable without partitioning it:
http://www.percona.com/blog/2009/11/16/table_cache-negative-scalability/
This doesn't directly apply to MariaDB. We didn't partition it
because our table definition cache is lock-free. There were quite a few
related changes in 10.0 (e.g. see MDEV-7292 and linked issues). In
short, we didn't partition it, because it doesn't need to be
partitioned. Not for this benchmark workload, at least.
Regards,
Sergei
I think original question was about 5.5.
MySQL 5.6 has partitioned table cache, but rather to overcome the
negative scalability aspect of increasing number of concurrent
connections.
No version of MariaDB has partitioned table cache. At least yet.
_______________________________________________
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help : https://help.launchpad.net/ListHelp
