Analyzing a MySQL table gives ERROR 1040 - Too many connections

Question

Why is it that when I run

ANALYZE TABLE table_name_here

The MySQL server starts giving out this error:

1040 - Too many connections

I've run this thru PHPMyAdmin btw..

And the table contains over 15 million rows of data. Is there a way to fix this?

MySQLTuner results:

-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.0.91-rs-log
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------
[--] Status: +Archive -BDB +Federated -InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 10G (Tables: 192)
[!!] Total fragmented tables: 14

-------- Security Recommendations  -------------------------------------------
ERROR 1142 (42000) at line 1: SELECT command denied
[OK] All database users have passwords assigned

-------- Performance Metrics -------------------------------------------------
[--] Up for: 21m 37s (134K q [103.756 qps], 982 conn, TX: 267M, RX: 20M)
[--] Reads / Writes: 88% / 12%
[--] Total buffers: 1.2G global + 22.2M per thread (120 max threads)
[!!] Maximum possible memory usage: 3.8G (99% of installed RAM)
[OK] Slow queries: 0% (4/134K)
[OK] Highest usage of available connections: 14% (17/120)
[OK] Key buffer size / total MyISAM indexes: 1.0G/2.9G
[OK] Key buffer hit rate: 97.7% (1M cached / 25K reads)
[OK] Query cache efficiency: 72.7% (92K cached / 127K selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 6K sorts)
[!!] Joins performed without indexes: 492
[!!] Temporary tables created on disk: 44% (490 on disk / 1K total)
[OK] Thread cache hit rate: 98% (17 created / 982 connections)
[OK] Table cache hit rate: 97% (262 open / 268 opened)
[OK] Open file limit used: 0% (463/65K)
[OK] Table locks acquired immediately: 99% (78K immediate / 78K locks)

-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    MySQL started within last 24 hours - recommendations may be inaccurate
    Reduce your overall MySQL memory footprint for system stability
    Adjust your join queries to always utilize indexes
    When making adjustments, make tmp_table_size/max_heap_table_size equal
    Reduce your SELECT DISTINCT queries without LIMIT clauses
Variables to adjust:
  *** MySQL's maximum memory usage is dangerously high ***
  *** Add RAM before increasing MySQL buffer variables ***
    join_buffer_size (> 10.0M, or always use indexes with joins)
    tmp_table_size (> 192M)
    max_heap_table_size (> 192M)

Originally my key buffer size was only set to 64MB. When I set the key buffer size to 1GB my maxed number of connected user only peaked at 17 while running that command. And when it was only set to 64MB it was always reaching the maximum allowed connected user. I can't set this to anything higher as my server is only limited to 4GB ram.

Answer 1

I'm moving my comment to a full answer here. This is a MySQL configuration issue and you may get a better answer on server fault.

The ANALYZE TABLE does two things that would cause your server problems. First is it is a command that takes a long time to run. From your too brief description of the problem I guessed that your application is doing very many short connections to the database. Since the ANALYZE takes a long time, the connection used while this is running is locked down. If the application is using connection pooling or has a application specific limit to number of connections it can make, I would set this to 3 short of the MySQL connection limit to allow you do perform work like this.

Second, ANALYZE TABLE, for MyISAM table rebuilds the indexes. Which means MySQL attempts to load the entire table into memory (or read the entire table) to build the indexes anew. This issues table locks against the table and takes a huge chunk of memory, which interferes with MySQL's ability to do other work (like run your application).

My real suggestion would be move to InnoDB rather than MyISAM. It does a much better job of managing memory, indexes, and data. It's faster than MyISAM for the table sizes you are dealing with and fewer headaches.