Hi Monty,
me and Axel did additional analysis of LOCK_open wait time in 10.0.4.
Below are a few interesting things that we discovered:
- with 1 CPU LOCK_open and THR_LOCK::mutex wait times are very close
- with 4 CPU LOCK_open wait time is about 5.5 * THR_LOCK::mutex wait time
- 5.6 with 4 CPU
Hi, Pavel!
On Aug 19, Pavel Ivanov wrote:
No, it's not reasonable for semi-sync to lock/unlock LOCK_plugin. It's
plugin infrastructure that does that.
I've actually was terrified to learn that each call into semi-sync
plugin is surrounded with pthread_rwlock_rdlock/pthread_rwlock_unlock
Hi, Pavel!
On Aug 20, Pavel Ivanov wrote:
On Tue, Aug 20, 2013 at 1:09 AM, Sergei Golubchik s...@mariadb.org wrote:
On Aug 19, Pavel Ivanov wrote:
No, it's not reasonable for semi-sync to lock/unlock LOCK_plugin.
It's plugin infrastructure that does that.
I've actually was terrified to
Is the workaround to use static rather than dynamic plugins?
On Tue, Aug 20, 2013 at 7:31 AM, Sergei Golubchik s...@mariadb.org wrote:
Hi, Pavel!
On Aug 20, Pavel Ivanov wrote:
On Tue, Aug 20, 2013 at 1:09 AM, Sergei Golubchik s...@mariadb.org
wrote:
On Aug 19, Pavel Ivanov wrote:
Mutex contention from various plugins
On Tue, Aug 20, 2013 at 9:12 AM, Pavel Ivanov piva...@google.com wrote:
Workaround for which problem?
On Tue, Aug 20, 2013 at 8:17 AM, MARK CALLAGHAN mdcal...@gmail.com
wrote:
Is the workaround to use static rather than dynamic plugins?
On Tue,
hi!
Another plugin that should be disabled is QUERY_RESPONSE_TIME. It has quite
some impact on LOCK_plugin:
-DWITH_QUERY_RESPONSE_TIME=1
+-++-+
| event_name | count_star | sum_timer_wait |
Is it reasonable for semi-sync to need to lock/unlock LOCK_plugin that
frequently? The plugin architecture, like most of the rest of MySQL, wasn't
described to people on the outside (like me).
On Mon, Aug 19, 2013 at 6:32 AM, Pavel Ivanov piva...@google.com wrote:
On Mon, Aug 19, 2013 at 5:17
hummm some doubts since i never used/write an audit plugin...
the lock_plugin of query response time, is a audit plugin + a
information schema plugin right?
he audit plugin is 'called' at query start and query end? or there's
more locks used?
when used the locked is used in what case? to lock the
Hi Axel,
thanks for testing and interesting results. Though our results diverge a lot,
generally I confirm that PFS is eating up 10-20% of performance and we're still
slower than 5.6. But in my scenario even single thread is about 10% slower than
in 5.6.
Further comments/questions inline.
From the above I'd say:
911 928 - number of executed queries (1x LOCK_tdc per query)
1 835 243 / 911 928= ~2 - LOCK_open was acquired 2x per query
4 194 896 / 911 928= ~4 - LOCK_plugin was acquired 4x per query
Most probably it means that table definition cache is full and every query
10 matches
Mail list logo
