Thank you Sergei, In fact, I have just identified last friday the config parameter that was causing trouble. => It was spider_conn_recycle_mode=1 Setting spider_conn_recycle_mode=0|2 solved my problem. I sent a stacktrace to Kentoku for analysis. I was already using the patched version of Kentoku as my spider nodes (mariadb-10.0.13-spider-3.2-vp-1.1-mroonga-4.05h). Though, my backend nodes are still on Mariadb 10.0.15 official release... -- Nicolas Le 12/01/2015 12:13, Sergei Golubchik a écrit :
Hi, Nicolas!
Hi list,
I am using Spider Storage Engine for sharding data and remote access to some innodb tables on 3 different MariaDB 10.0.14 instances.
It performs quite well in production except that sometimes, some queries (a minority of them fortunately) do not respond and stay indefinitely in "query end" state in processlist.
What can make a query stay indefinitely in "query end" state? Maybe a bug in Spider Storage Engine?
Any advice is welcome! I've asked the author of the Spider engine - Kentoku Shiba - and he
On Dec 19, Nicolas Payart wrote: thinks that these queries don't stay indefinitely, but are just very slow. They would be slow because, let me quote
... this case needs BKA join for better performance. But current table partition feature of official MariaDB does not support MRR well. In the other hand, there is a patched version of MariaDB that supports MRR well with partition feature. I will contribute this patch to official MariaDB.
meanwhile you can try the patched version of MariaDB (as prepared by Kentoku) with BKA and see if that helps:
Latest patched version of MariaDB source code http://spiderformysql.com/downloads/spider-3.2/mariadb-10.0.13-spider-3.2-vp... binary for Linux x86_64 http://spiderformysql.com/downloads/spider-3.2/mariadb-10.0.13-spider-3.2-vp...
Hmm, judging from the name this includes Spider 3.2, Vertical Partitioning engine 1.1 and Mroonga 4.05h
Regards, Sergei