는 ERROR 1040 제공 - 너무 많은 연결을

Question

이유를하다 내가 실행할 때

ANALYZE TABLE table_name_here 

MySQL 서버가이 오류 밖으로주고 시작합니다

1040 - 너무 많은 연결

나는 이것을 PHPMyAdmin btw를 통해 실행했습니다.

그리고이 테이블에는 1,500 만 개가 넘는 데이터 행이 있습니다. 이 문제를 해결할 수있는 방법이 있습니까?

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메가바이트로 설정했다. 키 버퍼 크기를 1GB로 설정하면 최대 접속 사용자 수는 해당 명령을 실행하는 동안 17시에 최고점에 도달했습니다. 그리고 64MB로만 설정되었을 때 항상 허용 된 최대 연결 사용자 수에 도달했습니다. 내 서버가 4GB RAM에만 국한되므로이 설정을 더 높게 설정할 수는 없습니다.

Answer 1

여기 내 대답을 전체 답변으로 이동합니다. 이것은 MySQL 구성 문제이며 서버 오류에 대한 더 나은 대답을 얻을 수 있습니다.

ANALYZE TABLE은 서버 문제를 일으키는 두 가지 일을합니다. 첫째, 실행하는 데 오랜 시간이 걸리는 명령입니다. 문제에 대한 귀하의 간단한 설명에서 귀하의 응용 프로그램이 데이터베이스에 매우 짧은 연결을하고 있다고 추측했습니다. ANALYZE는 오랜 시간이 걸리므로이 작업이 실행되는 동안 사용 된 연결은 잠겨 있습니다. 응용 프로그램이 연결 풀링을 사용하거나 연결 수에 대한 응용 프로그램 특정 제한이있는 경우이 작업을 수행 할 수 있도록 MySQL 연결 한계가 3 개 부족한 것으로 설정합니다.

둘째, ANALYZE TABLE은 MyISAM 테이블에 대해 인덱스를 다시 작성합니다. 즉, MySQL은 전체 테이블을 메모리에로드 (또는 전체 테이블 읽기)하여 인덱스를 다시 작성하려고합니다. 이 문제는 테이블에 대해 잠금을 설정하고 엄청난 양의 메모리를 필요로하며, 이는 MySQL의 다른 작업 (예 : 애플리케이션 실행)을 방해합니다.

나의 진정한 제안은 MyISAM이 아닌 InnoDB로 이동하는 것입니다. 메모리, 인덱스 및 데이터 관리가 훨씬 효율적입니다. MyISAM보다 처리 속도가 빠르고 두통이 적습니다.