Анализ таблицы MySQL дает ошибку 1040 - Слишком много соединений

Question

Почему когда я бегу

ANALYZE TABLE table_name_here

Сервер MySQL начинает выдавать эту ошибку:

1040 - Слишком много соединений

Я запустил это через PHPMyAdmin кстати..

И таблица содержит более 15 миллионов строк данных. Есть ли способ это исправить?

MySQLTuner результаты:

-------- 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)

Первоначально размер моего ключевого буфера был установлен на 64 МБ. Когда я установил размер буфера ключа в 1 ГБ, мое максимальное число подключенных пользователей достигло максимума только 17 во время выполнения этой команды. И когда он был установлен только на 64 МБ, он всегда достигал максимально разрешенного подключенного пользователя. Я не могу установить это на что-то более высокое, поскольку мой сервер ограничен только 4 ГБ оперативной памяти.

Answer 1

Я перехожу мой комментарий к полному ответу здесь. Это проблема конфигурации MySQL, и вы можете получить лучший ответ при сбое сервера.

ANALYZE TABLE выполняет две вещи, которые могут вызвать проблемы на вашем сервере. Во-первых, это команда, выполнение которой занимает много времени. Из вашего слишком краткого описания проблемы я догадался, что ваше приложение выполняет очень много коротких подключений к базе данных. Поскольку ANALYZE занимает много времени, соединение, используемое во время работы, заблокировано. Если приложение использует пул подключений или имеет определенное для приложения ограничение на число подключений, которое оно может установить, я бы установил для этого параметра значение 3, меньшее ограничения на количество подключений MySQL, чтобы позволить вам выполнять такую ​​работу.

Во-вторых, ANALYZE TABLE для таблицы MyISAM перестраивает индексы. Это означает, что MySQL пытается загрузить всю таблицу в память (или прочитать всю таблицу), чтобы заново построить индексы. Это вызывает блокировку таблицы для таблицы и занимает огромный кусок памяти, что препятствует способности MySQL выполнять другую работу (например, запускать ваше приложение).

Моим реальным предложением было бы перейти на InnoDB, а не на MyISAM. Он намного лучше справляется с управлением памятью, индексами и данными. Это быстрее, чем MyISAM для размеров таблицы, с которыми вы имеете дело, и меньше головной боли.