On Tue, Oct 20, 2009 at 1:05 AM, Michael Widenius <monty@askmonty.org> wrote:
Hi!
"MARK" == MARK CALLAGHAN <mdcallag@gmail.com> writes:
MARK> On Mon, Oct 19, 2009 at 5:52 AM, Sergei Golubchik <sergii@pisem.net> 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/..., 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-mysq... 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@gmail.com