maria-developers team mailing list archive
-
maria-developers team
-
Mailing list archive
-
Message #01321
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 ?
For SHOW TABLE_STATS, look at
http://bazaar.launchpad.net/~mysqlatfacebook/mysqlatfacebook/trunk/revision/53,
and also revisions 55 and 56
For SHOW USER_STATS see the big v4 google patch:
http://google-mysql-tools.googlecode.com/svn/trunk/mysql-patches/all.v4-mysql-5.0.37.patch.gz
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
work
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
yet).
--
Mark Callaghan
mdcallag@xxxxxxxxx
Follow ups
References