pbxt-discuss team mailing list archive

[Paul McCullagh <paul.mccullagh@xxxxxxxxx>]

They should work in my.cnf, because they work on the command line.

At least it has worked this way up till now.

Unless there has been some change in the meaning of PLUGIN_VAR_READONLY.

My working understanding is that PLUGIN_VAR_READONLY means that the  
parameter is not settable at runtime.

@Vlad, could you please check this with the latest version of MySQL.  
Thanks.

On Nov 1, 2010, at 6:36 PM, MARK CALLAGHAN wrote:

> I have this in my.cnf ...
> pbxt_index_cache_size=20G
> pbxt_record_cache_size=40G
> pbxt_flush_log_at_trx_commit=2
>
> but at runtime pbxt reports:
> pbxt_index_cache_size   32MB
> pbxt_record_cache_size  32MB
>
> Which makes sense as these appear to be read-only in ha_pbxt.cc from  
> release 1.1
>
> static MYSQL_SYSVAR_STR(index_cache_size, pbxt_index_cache_size,
>  PLUGIN_VAR_READONLY,
>  "The amount of memory allocated to the index cache, used only to
> cache index data.",
>  NULL, NULL, NULL);
>
>
> On Mon, Nov 1, 2010 at 7:02 AM, MARK CALLAGHAN <mdcallag@xxxxxxxxx>  
> wrote:
> > On Sat, Oct 30, 2010 at 9:19 AM, Paul McCullagh
> > <paul.mccullagh@xxxxxxxxx> wrote:
> > > Hi Mark,
> > >
> > > What has happened here is the index cache is full of dirty pages,  
> > > and needs
> > > to be flushed.
> > >
> > > When a thread hits this situation it starts a background thread to  
> > > flush the
> > > indexes. That is why we have xt_wait_for_async_tasks() in the top- 
> > > most stack
> > > trace.
> > >
> > > The background tasks are all busy flushing the indexes. One of the  
> > > problems
> > > here is that indexes are actually synced to disk before anything can
> > > continue (although this is unnecessary for an import - but there  
> > > is no way
> > > to tell PBXT that this is the case).
> > >
> > > Also, writing an index is "all-or-nothing" so since about 20 GB of  
> > > index
> > > data is dirty it probably all has to be written.
> >
> > These stacks occur long before the database files are 20G on disk.
> >
> > --
> > Mark Callaghan
> > mdcallag@xxxxxxxxx
>
>
>
> --
> Mark Callaghan
> mdcallag@xxxxxxxxx