我有一个在CentOS上运行的MySQL服务器。
最近我遇到了一个问题,每两天发生一次。 服务器运行得很快,但是确实很慢,直到我重新启动MySQL,然后返回到正常状态。
这发生在我几次,所以这次我运行service mysqld restart之前,我采取了2截图。
重启之前:
重启后:
我的大部分表格都是InnoDB,less数是MyISAM。 (4个MyISAM表,38个InnoDB表)
my.cnf文件:
[mysqld] bulk_insert_buffer_size = 8M concurrent_insert = 2 connect_timeout = 30 default-storage-engine = MyISAM innodb_buffer_pool_size=1300M innodb_file_per_table=1 interactive_timeout = 1000 join_buffer_size=128M key_buffer_size = 1200M local-infile=0 slow_query_log=1 long_query_time=0.5 #skip-grant-tables max_allowed_packet = 900M max_connections = 40000 max_heap_table_size = 256M max_user_connections = 10000 max_write_lock_count = 8 myisam_max_sort_file_size = 256M myisam_sort_buffer_size = 64M open_files_limit = 10192 query_alloc_block_size = 65536 query_cache_limit = 256M query_cache_size = 384M query_cache_type = 1 query_prealloc_size = 262144 range_alloc_block_size = 4096 read_buffer_size = 4M read_rnd_buffer_size = 16M sort_buffer_size = 4M table_cache = 8048 table_open_cache = 8000 thread_cache_size = 50 tmp_table_size = 256M transaction_alloc_block_size = 4096 transaction_prealloc_size = 4096 #innodb_force_recovery=5 wait_timeout = 1000 max_connect_errors = 5000 open-files = 50000 [mysqld_safe] log-error=/var/log/mysqld.log pid-file=/var/run/mysqld/mysqld.pid
SHOW GLOBAL STATUS LIKE'%connect%';
+--------------------------+--------+ | Variable_name | Value | +--------------------------+--------+ | Aborted_connects | 0 | | Connections | 859148 | | Max_used_connections | 103 | | Ssl_client_connects | 0 | | Ssl_connect_renegotiates | 0 | | Ssl_finished_connects | 0 | | Threads_connected | 1 | +--------------------------+--------+
SHOW GLOBAL VARIABLES like'thread_%';
+---------------------------+---------------------------+ | Variable_name | Value | +---------------------------+---------------------------+ | thread_cache_size | 50 | | thread_concurrency | 10 | | thread_handling | one-thread-per-connection | | thread_pool_idle_timeout | 60 | | thread_pool_max_threads | 500 | | thread_pool_oversubscribe | 3 | | thread_pool_size | 8 | | thread_pool_stall_limit | 500 | | thread_stack | 294912 | +---------------------------+---------------------------+
SHOW GLOBAL STATUS LIKE'threads_%';
+-------------------+-------+ | Variable_name | Value | +-------------------+-------+ | Threads_cached | 49 | | Threads_connected | 1 | | Threads_created | 372 | | Threads_running | 1 | +-------------------+-------+
SHOW GLOBAL STATUS LIKE'key_%';
+------------------------+---------+ | Variable_name | Value | +------------------------+---------+ | Key_blocks_not_flushed | 0 | | Key_blocks_unused | 1003901 | | Key_blocks_used | 3365 | | Key_blocks_warm | 0 | | Key_read_requests | 99176 | | Key_reads | 3052 | | Key_write_requests | 29353 | | Key_writes | 29347 | +------------------------+---------+
显示全局状态如“Q%”;
+-------------------------+-----------+ | Variable_name | Value | +-------------------------+-----------+ | Qcache_free_blocks | 961 | | Qcache_free_memory | 400828904 | | Qcache_hits | 1634009 | | Qcache_inserts | 1201887 | | Qcache_lowmem_prunes | 0 | | Qcache_not_cached | 59970 | | Qcache_queries_in_cache | 1467 | | Qcache_total_blocks | 3926 | | Queries | 5316596 | | Questions | 5187929 | +-------------------------+-----------+
显示全局variables像'_size';
Empty set
这似乎是更多的客户端加载问题,而不是一个内存泄漏的服务器问题。 守护进程的线程正在咀嚼大约一个或两个核心。 他们忙什么? SHOW FULL PROCESSLIST是什么意思?
重启过程比重置守护进程的状态要多得多。 它吹走了大概有活动端口3306(或AF_UNIX)连接到服务器的587个进程。 他们在干什么? 你对他们在做什么感到满意吗? 他们在重新启动时logging了致命的错误,使你不快乐吗? 他们是否应该完成一些任务,然后断开和退出?
重新启动是一个快速的解决scheme,但是您似乎希望了解在重新启动之前的48小时内,客户端负载如何变得越来越大。
在阅读您的参考手册后,要立即获得解决,请考虑
set global read_rnd_buffer_size=256K; # from 16M per connection
这可以dynamic完成。
login完成后,每个login不需要16M。 为什么要读16M(即使是从RAM中)256K会好? 张贴其他要求的项目后,我会有额外的build议。
—– 2017 11 04 ————-以下build议需要您的研究,每天只实施一个项目。 有些可能会dynamic应用。 build议的cfg / ini值遵循[mysqld]部分,可以修改,添加或删除。
max_connections=200 #from 40000 to support your 103 max_used_connections max_user_connections=200 #from 10000 to be matched with max_connections key_buffer_size REMOVE for default of 64M. less than 1% of 1200MB used thread_cache_size=100 #from 50 to support your 103 max_used_connections - cap at 100 per V8 thread_concurrency=33 #from 10 for about 30% active max_connect_errors=10 #from 5000, to better control hacker passwd guessing innodb_print_all_deadlocks=1 # from OFF, if you ever have one, you need this data in error log #### these are PER CONNECTION values driving your RAM footprint up the wall #read_buffer_size or REMOVE for default of 128K vs 4M RAM #read_rnd_buffer_size or REMOVE for default of 256K vs 16M RAM #join_buffer_size or REMOVE for default of 128K vs 128MB RAM
使用MySQLCalculator.com将帮助你看到多less内存你可能需要,如果40000并发连接可能会成功(不太可能发生) – appx 6兆字节的RAM将是必需的。
要进一步分析所反映的变化的结果,在7天的正常运行时间之后,请发布完整的文本结果
SHOW GLOBAL STATUS; SHOW GLOBAL VARIABLES; SHOW ENGINE INNODB STATUS;
并转发完成my.cnf。