put threads with GLOBAL READ lock (executing ftwrl) into high priority queue

Bug #1374930 reported by zhai weixiang
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Percona Server moved to https://jira.percona.com/projects/PS
Status tracked in 5.7
5.5
Won't Fix
Wishlist
Unassigned
5.6
Fix Released
Wishlist
Laurynas Biveinis
5.7
Fix Released
Wishlist
Laurynas Biveinis

Bug Description

Version: Percona Server 5.6.19

1. With thread pool enabled:
root@sb 05:49:05>show variables like '%thread%pool%';
+-------------------------------+--------------+
| Variable_name | Value |
+-------------------------------+--------------+
| thread_pool_high_prio_mode | transactions |
| thread_pool_high_prio_tickets | 4294967295 |
| thread_pool_idle_timeout | 60 |
| thread_pool_max_threads | 100000 |
| thread_pool_oversubscribe | 3 |
| thread_pool_size | 32 |
| thread_pool_stall_limit | 30 |
+-------------------------------+--------------+
7 rows in set (0.00 sec)

2. start sysbench , with high concurrency updates, for example, 500 threads

3.
root@(none) 05:51:37>flush tables with read lock;
Query OK, 0 rows affected (0.01 sec)

root@(none) 05:51:44>show processlist; ----------- hang in same session.

^C^Z

I think it's better to put threads that own global mdl lock (by executing FLUSH TABLES WITH READ LOCK) into high priority queue.
PS : I am not completely sure if this is the exact reason that lead to hang. Still working on this issue.

summary: - put threads with GLOBAL MDL lock (executing ftwrl) into high priority
+ put threads with GLOBAL READ lock (executing ftwrl) into high priority
queue
Revision history for this message
zhai weixiang (zhaiwx1987) wrote :

A simple patch to prove the problem..

$svn diff sql/threadpool_unix.cc
Index: sql/threadpool_unix.cc
===================================================================
--- sql/threadpool_unix.cc (revision 7085)
+++ sql/threadpool_unix.cc (working copy)
@@ -444,7 +444,8 @@

   return (mode == TP_HIGH_PRIO_MODE_STATEMENTS) ||
     (mode == TP_HIGH_PRIO_MODE_TRANSACTIONS &&
- c->tickets > 0 && thd_is_transaction_active(c->thd));
+ c->tickets > 0 && thd_is_transaction_active(c->thd)) ||
+ c->thd->global_read_lock.is_acquired();
 }

 } // namespace

Revision history for this message
zhai weixiang (zhaiwx1987) wrote :

I think metadata lock should be taken into consideration while deciding if a thread has a high priority.

Revision history for this message
Laurynas Biveinis (laurynas-biveinis) wrote :

IMHO makes sense

tags: added: performance threadpool
Revision history for this message
Laurynas Biveinis (laurynas-biveinis) wrote :
Revision history for this message
Shahriyar Rzayev (rzayev-sehriyar) wrote :

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PS-2451

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.