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  Edit
Everyone can see this information.

Other bug subscribers