Hi Sergei, On Wed, Aug 31, 2016 at 04:47:09PM +0200, Sergei Golubchik wrote:
Hi, Sergey!
On Aug 03, Sergey Vojtovich wrote:
On Jun 29, Sergey Vojtovich wrote:
revision-id: 48d1ba6097939efe5efd28dd3ed9d281cc2bc2f4 (mariadb-10.2.0-93-g48d1ba6) parent(s): 8bec9746f0d5b363f385713035ca3f2daff34e1c committer: Sergey Vojtovich timestamp: 2016-06-29 16:33:08 +0400 message:
MDEV-10296 - Multi-instance table cache
Improve scalability by implementing multi-instance table cache.
diff --git a/mysql-test/suite/sys_vars/r/sysvars_server_notembedded.result b/mysql-test/suite/sys_vars/r/sysvars_server_notembedded.result index e075c64..22b12a9 100644 --- a/mysql-test/suite/sys_vars/r/sysvars_server_notembedded.result +++ b/mysql-test/suite/sys_vars/r/sysvars_server_notembedded.result @@ -4559,6 +4559,20 @@ NUMERIC_BLOCK_SIZE 1 ENUM_VALUE_LIST NULL READ_ONLY NO COMMAND_LINE_ARGUMENT REQUIRED +VARIABLE_NAME TABLE_OPEN_CACHE_INSTANCES +SESSION_VALUE NULL +GLOBAL_VALUE 1 +GLOBAL_VALUE_ORIGIN COMPILE-TIME
Default value 1 and it's not auto-tuned on startup? You think multi-instance table cache is better stay unused? :) If not, either use a reasonable default or, may be, choose it on startup based on my_gencpus() Yes, I think multi-instance table cache is better stay unused probably in 99% of installations. E.g. 2 CPU / 20 cores / 40 threads Broadwell is 95% satisfied by single instance.
Well... If you add a feature that is "better stay unused probably in 99% of installations" and disable it by default, it will not be used at all. One very valid "internal" use case is benchmarking. At least Intel and IBM were interested in improved single table load scalability. There're also numerous writings that blame MariaDB for bad scalability compared to MySQL. This patch aims to solve one of the bottlenecks.
Let's think how we can make this feature used, is autosizing the only option?
Used among those estimated 1% who has powerful enough hardware? Not sure, probably explain this in manual? Thanks, Sergey