← Back to team overview

pbxt-discuss team mailing list archive

Re: question about support for concurrent IO

 

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




References