pt-query-digest - what is being reported in the queue wait attribute

Hello -
Running Percona Server 5.5.38-35.2-log, and looking at the pt-query-digest report from our slow log (set to 2 seconds). Many of the queries reported are simple index-supported SELECTS, but they are showing the majority of the time as “queue wait”. I’ve been researching, but it is not clear to me what that is counting. Can someone shed some light on what that means? Here is an example

Query 1: 0.03 QPS, 0.08x concurrency, ID 0x2A76B7CFBB6C34B4 at byte 3204805

This item is included in the report because it matches --limit.

Scores: V/M = 0.19

Time range: 2015-01-26 15:33:56 to 22:00:41

Attribute pct total min max avg 95% stddev median

============ === ======= ======= ======= ======= ======= ======= =======

Count 9 614

Exec time 8 1761s 2s 5s 3s 5s 729ms 3s

Lock time 2 48ms 42us 188us 78us 108us 18us 73us

Rows sent 0 613 0 1 1.00 0.99 0.04 0.99

Rows examine 0 2.10k 0 11 3.50 6.98 1.52 2.90

Rows affecte 0 0 0 0 0 0 0 0

Rows read 0 2.10k 0 11 3.50 6.98 1.52 2.90

Bytes sent 3 929.06k 1.45k 2.41k 1.51k 1.53k 47.83 1.46k

Merge passes 0 0 0 0 0 0 0 0

Tmp tables 0 0 0 0 0 0 0 0

Tmp disk tbl 0 0 0 0 0 0 0 0

Tmp tbl size 0 0 0 0 0 0 0 0

Query size 10 462.38k 766 772 771.13 755.64 0 755.64

InnoDB:

IO r bytes 0 0 0 0 0 0 0 0

IO r ops 0 0 0 0 0 0 0 0

IO r wait 0 0 0 0 0 0 0 0

pages distin 0 2.65k 2 10 4.41 6.98 1.46 3.89

queue wait 20 1608s 0 5s 3s 4s 998ms 3s

rec lock wai 0 0 0 0 0 0 0 0

String:

Databases xxx

Hosts

InnoDB trxID 296D614CEE (1/0%), 296D614CEF (1/0%)… 612 more

Last errno 0

Users xxx

Query_time distribution

1us

10us

100us

1ms

10ms

100ms

1s ##################################################

10s+

Tables

Hi,
As stated in http://www.percona.com/doc/percona-server/5.1/diagnostics/slow_extended.html?id=percona-server:features:slow_extended_51&redirect=2 , this is an additional statistics added in the slow log entry. As stated in that link:

innodb_queue_wait: Shows how long (in seconds) the query spent either waiting to enter the InnoDB queue or inside that queue waiting for execution.