On Mon, Apr 13, 2009 at 2:45 PM, Michael Widenius <monty@askmonty.org> wrote:
Hi!
"Sergei" == Sergei Golubchik <sergii@pisem.net> writes:
Sergei> Hi, Michael! Sergei> On Mar 18, Michael Widenius wrote:
>> "Sergei" == Sergei Golubchik <sergii@pisem.net> writes:
Sergei> Hi, Michael! Sergei> On Mar 12, Michael Widenius wrote:
#At lp:maria based on revid:monty@askmonty.org-20090309141344-wriztb0fcn00syim
2680 Michael Widenius 2009-03-13 Added "pool-of-threads" handling (with libevent) This is a backport of code from MySQL 6.0 with cleanups and extensions
The following new options are supported configure options: --with-libevent ; Enable use of libevent, which is needed for pool of threads
Sergei> Are you aware of the current scalability problems with the pool of Sergei> threads in 6.0 ? What are you going to do about it ?
No, haven't followed this discussion. Will look for it.
Sergei> Just found something relevant: http://bugs.mysql.com/42288
Thanks; Read this with a great deal of interest and was looking at the code involving LOCK_event_loop mutex to understand the problem.
It's totally understandable why this happens; All waiting is now done on this mutex, as only one thread can be inside the event_loop() at the same time.
The original code for Solaris didn't have any mutex that was hold for more than a couple of instructions, which should make it notable faster.
Need to study the event_loop() code to know how tread safe this part of the code is.
The fix for our backport to 5.0.37 is likely to use epoll and be Linux only, removing our dependency on many lines of libevent code. The performance fix for us is to shard the mutex into a few mutexes and statically assign file descriptors to one of the mutexes and all that it protects. We are still debating whether migration of file descriptors between mutexes is needed. From a reading of the memcached code, they don't migrate. So, replacing the one big mutex with several smaller mutexes might work. libevent still has a bit more overhead on Linux as it does not support EPOLLONESHOT so that extra work, a system call, is needed to remove the file descriptor from the set of listening file descriptors when data is ready for it and the mutex is held when this is done. Also, after each command is run the code path to return the file descriptor back to the set of listening descriptors is a bit complex and expensive.
Regards, Monty
_______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
-- Mark Callaghan mdcallag@gmail.com