You are investigating the performance of the server and see the following information:
Events_waits_summary_global_by_event_name in the performance schema shows that the
wait/synch/mutex/sql/LOCK_table_cache event is dominating other wait events.
The table_open_cache_overflows status variable is 0.
Which action should be taken to remove the performance bottleneck described here?
A.
Decrease the value of table_definition_cache.
B.
Increase the value of table_definition_cache.
C.
Decrease the value of table_open_cache.
D.
Increase the value of table_open_cache.
E.
Decrease the value of table_open_cache_instances.
F.
Increase the value of table_open_cache_instances.
Explanation:
A,D
F.
I believe F as well.
http://planet.mysql.com/entry/?id=34237
I think DF
http://dev.mysql.com/doc/refman/5.6/en/server-status-variables.html#statvar_Table_open_cache_overflows
But why F if table_open_cache_overflows=0 !!
F
Table_open_cache_overflows
The number of overflows for the open tables cache. This is the number of times, after a table is opened or closed, a cache instance has an unused entry and the size of the instance is larger than table_open_cache / table_open_cache_instances. This variable was added in MySQL 5.6.6.
I believe D
F
https://dev.mysql.com/doc/refman/5.6/en/server-system-variables.html#sysvar_table_open_cache_instances
The number of open tables cache instances (default 1). To improve scalability by reducing contention among sessions, the open tables cache can be partitioned into several smaller cache instances of size table_open_cache / table_open_cache_instances . A session needs to lock only one instance to access it for DML statements. This segments cache access among instances, permitting higher performance for operations that use the cache when there are many sessions accessing tables. (DDL statements still require a lock on the entire cache, but such statements are much less frequent than DML statements.)
F