MySQL Proxy: profiling 0.8

August 6th, 2009

In MySQL Proxy 0.8 we are added a multi-threaded network-subsystem allowing several networks events be processed in parallel. Early benchmarks show that what we have in trunk basicly works.

But the benchmarks weren't as good as we expected. That's the time where you prepare to get dirty.

While Kay went with lockstat to analyze the proxy on solaris and found that g_atomic_int_get() isn't using native code if built with Sun's CC, I attacked the Linux side with oprofile.

After rebuilding the proxy with -fno-omit-frame-pointer I got the information I was looking for from oprofile:

$ opcontrol --vmlinux=...
$ opcontrol --callgraph=5
$ opcontrol --separate=lib,kernel
$ opcontrol --start
$ sysbench ...
$ opcontrol --stop
$ opreport \
    --debug-info \
    --callgraph \
    --symbols \
    --merge tgid \
    '.../mysql-proxy'
....
-------------------------------------------------------------------------------
  1224     20.3966  event.c:468                 libevent-1.4.so.2.1.1    event_base_loop
  4777     79.6034  network-mysqld.c:446        libmysql-proxy.so.0.0.0  plugin_call
102069    2.7567  (no location information)   libpthread-2.5.so        pthread_mutex_lock
  102069   100.000  (no location information)   libpthread-2.5.so        pthread_mutex_lock [self]
...

The global Lua lock, the lock we wanted to remove for 0.9 anyway. Perhaps we can do something simple and not take the lock if there is no Lua script loaded. In 0.9 we will change the implementation and give each connection its own Lua state instead of shared the state between all connections.

2 Responses to “MySQL Proxy: profiling 0.8”

  1. Mark Callaghan Says:
    I thought that Lua did not have a GIL (global interpreter lock). Is my memory wrong? Regardless, this makes the proxy better. Nice work.
  2. Jan Kneschke Says:
    Lua doesn't have one. It is just our old way of creating a global namespace between the connections. In 0.9 we plan to use message passing between the threads to share global structures (like runtime, config, stats, ...) between the connections in Lua land. We will give each connection its own Lua_state making them completely independent.

Sorry, comments are closed for this article.