Comment 3 for bug 1222694

<Roel> (gdb) thread apply all bt
<Roel> +thread apply all bt
<Roel> Thread 1 (process 5354):
<Roel> +bt
<Roel> #0 0x0000003636edf253 in poll () from /lib64/libc.so.6
<Roel> #1 0x00000000005a450a in handle_connections_sockets () at /bzr/5.6-QA_dbg/Percona-Server-5.6.13-rc60.5/sql/mysqld.cc:6259
<Roel> #2 0x00000000005ab4eb in mysqld_main (argc=76, argv=0x2ca0228) at /bzr/5.6-QA_dbg/Percona-Server-5.6.13-rc60.5/sql/mysqld.cc:5674
<Roel> #3 0x0000003636e1ecdd in __libc_start_main () from /lib64/libc.so.6
<Roel> #4 0x000000000059c785 in _start ()
<Roel> that's it (return to prompt)
<Roel> laurynas,
<Roel> [roel@qaserver 528526]$ /ssd/Percona-Server-5.6.13-rc60.5-440-debug.Linux.x86_64/bin/mysqladmin --socket=/ssd//528526/current1_2/tmp/master.sock ping
<Roel> no prompt return
<laurynas> I don't understand why it's only one thread
<laurynas> where did the rest go
<Roel> idem
<laurynas> error log?
<Roel> good one, checking
<Roel> 2013-09-18 06:44:56 5354 [Note] /ssd/Percona-Server-5.6.13-rc60.5-440-debug.Linux.x86_64/bin/mysqld: ready for connections.
<Roel> Version: '5.6.13-rc60.5-debug-log' socket: '/ssd//528526/current1_2/tmp/master.sock' port: 13020 Percona Server with XtraDB (GPL), Release rc60.5, Revision 440-debug
<Roel> 2013-09-18 06:45:39 5354 [ERROR] Threadpool could not create additional thread to handle queries, because the number of allowed threads was reached. Increasing 'thread_pool_max_threads' parameter can help in this situation.
<Roel> If 'extra_port' parameter is set, you can still connect to the database with superuser account (it must be TCP connection using extra_port as TCP port) and troubleshoot the situation. A likely cause of pool blocks are clients that lock resources for long time. 'show processlist' or 'show engine innodb status' can give additional hints.
<Roel> 2013-09-18 06:45:39 5354 [Note] Threadpool has been blocked for 30 seconds
<Roel> ah
<Roel> [roel@qaserver 528526]$ grep "thread.pool.max.threads" /ssd/randgen/conf/percona_qa/5.6/5.6.yy
<Roel> SET GLOBAL thread_pool_max_threads = zero_to_thousand |
<Roel> still, seems odd?
<laurynas> hmm wait
<laurynas> Roel: zero is not a valid value for tread_pool_max_threads
<Roel> good qa includes boundary value testing :)
<laurynas> with low max thread number tpool might become blocked by design
<Roel> zero_to_thousand:
<Roel> 0 | 1 | 2 | 10 | 100 | 150 | 200 | 250 | 300 | 400 | 500 | 600 | 650 | 700 | 800 | 900 | 999 | 1000 ;
<laurynas> but I still have no idea where did the rest of threads go
<laurynas> zero is invalid-invalid, as in, value range checks will reject it outright
<Roel> ack
<laurynas> now 1 and 2 will stop the server, and probably 10 too
<Roel> but that " Threadpool has been blocked for 30 seconds" was posted ~3-4 hours ago...
<laurynas> Roel: 100 150 200 300 500 600 1000 value list should be OK (even that is long-ish)
<Roel> nothing since then
<Roel> laurynas, should the message not repeat...
<Roel> and the server still reply to pings
<Roel> etc.
<laurynas> not with threadpool
<Roel> cpu's are idle, so no loops
<laurynas> pings go as an incoming request, which I guess needs a worker thread and there are none
<Roel> right
<Roel> laurynas, not all values are tested, they are just picked randomly
<Roel> ok so I'll change that then
<laurynas> OK