put threads with GLOBAL READ lock (executing ftwrl) into high priority queue
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_
| thread_
| thread_
| thread_
| thread_
| thread_pool_size | 32 |
| thread_
+------
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 |
A simple patch to prove the problem..
$svn diff sql/threadpool_ unix.cc unix.cc ======= ======= ======= ======= ======= ======= ======= ======= ==== unix.cc (revision 7085) unix.cc (working copy)
Index: sql/threadpool_
=======
--- sql/threadpool_
+++ sql/threadpool_
@@ -444,7 +444,8 @@
return (mode == TP_HIGH_ PRIO_MODE_ STATEMENTS) || PRIO_MODE_ TRANSACTIONS && transaction_ active( c->thd) ); transaction_ active( c->thd) ) || >global_ read_lock. is_acquired( );
(mode == TP_HIGH_
- c->tickets > 0 && thd_is_
+ c->tickets > 0 && thd_is_
+ c->thd-
}
} // namespace