?

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: jamesd
date: Jan. 2nd, 2008 04:09 pm (UTC)
Link

Good to see. Next stop some way to prevent all of the threads being taken by slow queries that cause the server to hit max_connections by not letting the (often) far more frequent fast queries run. I assume that it's possible for the optimiser to say that query x is expected to take n operations and have a pool for tasks expected to be "fast" where fast's n is user-configurable.

Reply | Thread

Brian "Krow" Aker

(no subject)

from: krow
date: Jan. 2nd, 2008 06:22 pm (UTC)
Link

Not yet. The code for these two items are entirely on different layers (and the server really is not designed for this sort of way of thinking).

Not even using the SQL hints would work.

Perhaps if the user gave a hint in he way of a flag... or this could possibly be done with prepared statements (where the original cost could be stored and used for priority).

Reply | Parent | Thread

(no subject)

from: jamesd
date: Jan. 3rd, 2008 03:33 am (UTC)
Link

Not really keen on SQL hints for this. More something that I think belongs in the storage engines with just a work estimate or row estimate clue from the optimiser. Then the storage engine can do whatever makes sense for its own implementation, like knowing if/when disk accesses are required and perhaps using that to decide finally that something is slow if the engine does the disk work itself. Perfection not required, just good enough.

Still, definite progress being made here even if I immediately start thinking of other things that would be helpful... :)

Reply | Parent | Thread

Brian "Krow" Aker

(no subject)

from: krow
date: Jan. 3rd, 2008 03:47 am (UTC)
Link

I dislike SQL hints has well....

I've pointed Kostja and Dmitri at your comments. Hopefully they will respond.

Reply | Parent | Thread