Log in

No account? Create an account

MySQL 6.0, Libevent

« previous entry | next entry »
Jan. 1st, 2008 | 11:30 am

Currently in the 6.0 tree we have support for Libevent. This is one of those things I've been wanting to see
us do for years and it was finally completed a few weeks ago by Damien
Katz (aka CouchDB) with some help from Dmitri Lenev.

So what does this do? MySQL uses a 1:1 ratio for connections and
threads. Libevent allows us to pull threads into pools and use them
for connections. This is pretty awesome for 8way machines since
partially solves thread contention issues. Below is an example of
MyISAM doing large number of inserts with the number of users doing
inserts increasing (1-300 users). The graph shows the time taken for
each test run. Similar numbers show up when you run benchmarks with
Innodb (leave concurrent set to zero as you should normally do, this
will allow libevent to more effectively control the thread usage).
The green line shows the test running with 20 threads, while the blue
is unlimited. I do not have good rules of thumb yet for thread number
vs processors. The machine I used for this test is an 8way that I have
on loan from Intel. I will work out a similar test for Solaris once I
can get the code to compile there.

Pretty awesome :)
Libevent Picture.jpg

Link | Leave a comment |

Comments {17}


(no subject)

from: peter_zaitsev
date: Jan. 5th, 2008 06:03 pm (UTC)

Sure. It is quite expected to work well for CPU bound case with short queries.

James brings one tricky issue - how do you make sure all slots are not busy by complex queries so small queries starve.

There are more tricky issues - for example how to maintain true concurrency - threads may well be stalled waiting on the row level locks, disk IO waits is another great example.

To implement it working for large number of cases much larger overhaul is needed having MySQL kernel to control concurrency so waiting threads allow someone else to run.

But this is surely great first step.

Reply | Thread

Brian "Krow" Aker

(no subject)

from: krow
date: Jan. 6th, 2008 12:29 am (UTC)

Agreed, this is mainly for a setup where the database is doing all lightweight queries. You could keep down long queries by running them under one user and limiting concurrent connections.

Good start, but yes, it is going to need more to work in a way so that no one will shoot themselves in the foot.

Reply | Parent | Thread