← Back to team overview

maria-developers team mailing list archive

Re: Userstats patch applied to MariaDB 5.2


On Tue, Oct 20, 2009 at 1:05 AM, Michael Widenius <monty@xxxxxxxxxxxx> wrote:
> Hi!
>>>>>> "MARK" == MARK CALLAGHAN <mdcallag@xxxxxxxxx> writes:
> MARK> On Mon, Oct 19, 2009 at 5:52 AM, Sergei Golubchik <sergii@xxxxxxxxx> wrote:
>>> Hi, Monty!
>>> On Oct 19, Michael Widenius wrote:
>>>> I just finished applying / modifying / rewriting the userstats patch
>>>> to MariaDB 5.2 and will commit this in a moment.
>>> I wonder if anybody cares to monitor mutex usage in MySQL.
>>> This patch adds few new global mutexes that are locked at least once per
>>> statement (or more).
>>> Without benchmark results one can only speculate whether it will affect
>>> users or not.
> MARK> I am willing to bet that Monty's patch makes sysbench readonly much
> MARK> slower with high concurrency on an 8-core server. But those problems
> MARK> have been fixed in recent versions of the patch.
> One should note that I changed the patch so that there is minimal
> overhead (in the order of 4 if) if the userstat is not enabled (ie,
> the userstat variable is not set)

I should have run tests first. Fortunately I didn't bet a lot of
money. I will do that now (test v4 google patch, maria 5.2, 5.0.37
unmodified, 5.1.38 unmodified with 1.0.4 plugin) and confirm or deny
my claim.

I measured approximately zero overhead from the SHOW TABLE_STATS
feature in the Facebook patch listed below using sysbench readonly on
an 8-core server.

> Where can I find that newer version of the patch or can you describe
> what changes needs to be done ?

and also revisions 55 and 56

For SHOW USER_STATS see the big v4 google patch:

The key to making SHOW TABLE_STATS faster is:
* cache pointers into global_table_stats using handler::version_table_stats
* updating stats prior to getting LOCK_open when possible (see bzr
revision 53 above)
* remove code for SHOW INDEX_STATS, doing that efficiently requires
more changes than I am willing to maintain -- someone should fund that

The key to making SHOW USER_STATS faster is:
* cache pointers into global_user_stats using THD::thd_user_stats_version
* get rid of the code that computes concurrent connections per account

I want to review your changes to see whether I can reuse your
improvements for my code.

Both table and user stats would be cleaner were the stats stored in an
existing global user or table object. I think such an object exists
for user but not for table (the 'shared' table object isn't shared

Mark Callaghan

Follow ups