maria-developers team mailing list archive

[Sergey Vojtovich <svoj@xxxxxxxxxxx>]

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