[MDEV-7292] Table_open_cache scalability issues Created: 2014-12-08  Updated: 2015-01-12  Resolved: 2015-01-12

Status: Closed
Project: MariaDB Server
Component/s: OTHER
Affects Version/s: 10.0.15
Fix Version/s: 10.0.16

Type: Bug Priority: Major
Reporter: Guillaume Lefranc Assignee: Sergey Vojtovich
Resolution: Incomplete Votes: 2
Labels: None
Environment:

Debian wheezy x86_64

Issue Links:
Relates
relates to MDEV-5388 Reduce usage of LOCK_open: unused_tables Closed
relates to MDEV-5864 Reduce usage of LOCK_open: TABLE_SHAR... Closed

 Description   

Hello,

in spite of recent effors, table_open_cache still seems to be hit by negative scalability. I ran the following benchmark tests:

  • SET GLOBAL table_open_cache = 64
  • Create 10,000 MyISAM Tables with a single integer
  • Access all tables in a loop
  • SET GLOBAL table_open_cache = 4000
  • Access all tables in a loop

Results are the following:
Table creation: 4s (sync_frm=0)
SELECT, Table_open_cache=64: 1.696519199s
SELECT, Table_open_cache=4000: 5.946816624s

The results are quite consistent and performance seems to decrease linearly.

My biggest concern is that MariaDB 5.5.40 is 2x faster with this test:

Selecting from tables with default cache (64)
Time: 1.536537015s
Selecting from tables with extended cache (4000)
Time: 2.798534456s

The only good news is that MySQL 5.6 seems to do worse with this test, with 6s and 9s respectively.

 Comments   
Comment by Sergey Vojtovich [ 2014-12-23 ]

We did improve scalability issues of concurrent connections accessing table cache. That is increased throughput of systems with high connection counts.

In all your examples (even 5.5.40) table_open_cache=64 shows better performance. So what's the point of high table_open_cache for such load?

Comment by Sergey Vojtovich [ 2015-01-12 ]

To fix this bug properly we need to understand reasons for setting high table_open_cache for such load. Closing this bug as incomplete for now. Feel free to reopen it with additional information.

Generated at Thu Feb 08 07:18:29 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.