Percona tmp table issue

Question

I have configured XtraDB cluster in three nodes. All the three servers has same MySQL configurations, 32 GB RAM and CentOS 5. The Server version is 5.5.29-23.7.1 (64 bit).

During the load test we are getting the Too Many Connection error. I have found that MySQL process list occupied with creating tmp table statements which leads to reaching the Thread connection threshold value 1000.

The creating tmp table issue occurs randomly in one server, other two servers are working as expected.

Please let me know increasing the tmp table size will fix this issue or any thoughts why this issue happens,

The Current my.cnf values,

## Temp Tables
    tmp-table-size = 256M
    max-heap-table-size = 128M

## Networking
    max-connections = 1000

Answer 1

If you can fit more of your temp tables in memory, it'll be faster and you'll get better throughput.

You probably don't want to set tmp_table_size greater than max_heap_table_size. It won't do any harm, but the effective limit on an in-memory temp table is the smaller of those two values. That is, max_heap_table_size is the limit on any kind of in-memory table. So you should increase max_heap_table_size=256M if you want to allow temp tables that large to stay in memory.

But this doesn't answer the question of whether 256M is large enough. I.e. you might need 500M temp tables, so they'll go to disk even if you allow 256M temp tables. You need to find out how much storage your temp tables need, and the only way currently to get this information is with Percona Server's verbose slow-query log. See http://www.percona.com/doc/percona-server/5.5/diagnostics/slow_extended_55.html

Keeping your temp tables in memory can improve performance somewhat, but it's much better if you can optimize your queries to avoid creating temp tables in the first place. Whether you can do this depends on the way the query is written. So you may need to create new indexes, or change the way some of your queries are written. There isn't a quick answer to this, unfortunately.