共计 3038 个字符,预计需要花费 8 分钟才能阅读完成。
如题,本章次要讲下当服务器呈现 ERROR 1040: Too many connections
谬误时的一些解决心得。
max_connections 查看
## 查看最大连接数
SHOW VARIABLES LIKE "max_connections";
+-----------------+-------+
| Variable_name | Value |
+-----------------+-------+
| max_connections | 512 |
+-----------------+-------+
## 查看已应用最大连接数
SHOW VARIABLES LIKE 'Max_used_connections';
+----------------------+-------+
| Variable_name | Value |
+----------------------+-------+
| Max_used_connections | 499 |
+----------------------+-------+
解决计划
这个问题个别有两种解决计划,解决方案非常容易,咱们只须要减少 max_connections
连接数即可。
减少以后会话的 mysql 最大连接数
SET GLOBAL max_connections = 1000;
下面 mysql 连贯值长期减少到 1000,但仅实用于以后会话。一旦咱们重新启动 mysql 服务或重新启动零碎,该值将重置为默认值。
永恒减少 mysql 最大连接数
为了永恒减少 mysql 连接数,咱们须要编辑 mysql 配置文件,即/etc/my.cnf
。
sudo vim /etc/my.cnf
## 批改
max_connections = 1000
保留文件重启 MySQL 即可失效。
扩多少适合?
Max_connextions
并不是越大越好的,那么如何配置?
形式一
对于进步 MySQL 的并发,很大水平取决于内存,官网提供了一个对于 innodb
的内存计算形式:
innodb_buffer_pool_size
+ key_buffer_size
+ max_connections * (sort_buffer_size + read_buffer_size + binlog_cache_size)
+ max_connections * 2MB
形式二
装置比例扩容:
max_used_connections / max_connections * 100% = [85, 90]%
最大应用连接数 / 最大连接数
达到了 80%~90% 区间,就倡议进行优化或者扩容了。
扩大
以下也波及几种常见的影响 MySQL 性能的状况:
线程
SHOW STATUS LIKE 'Threads%';
+-------------------+--------+
| Variable_name | Value |
+-------------------+--------+
| Threads_cached | 1 |
| Threads_connected | 217 |
| Threads_created | 29 |
| Threads_running | 88 |
+-------------------+--------+
SHOW VARIABLES LIKE 'thread_cache_size';
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| thread_cache_size | 10 |
+-------------------+-------+
- Threads_cached 线程在缓存中的数量
- Threads_connected 以后关上的连接数
- Threads_created 创立用于解决连贯的线程数。
- Threads_running 未休眠的线程数
如果 Threads_created 大,则可能要减少 thread_cache_size 值。缓存未命中率能够计算为 Threads_created / Connections
查看表锁状况
SHOW GLOBAL STATUS LIKE 'table_locks%';
+-----------------------+-------+
| Variable_name | Value |
+-----------------------+-------+
| Table_locks_immediate | 90 |
| Table_locks_waited | 0 |
+-----------------------+-------+
- Table_locks_immediate 立刻取得表锁申请的次数
- Table_locks_waited 无奈立刻取得对表锁的申请的次数,须要期待。这个值过高阐明性能可能呈现了问题,并影响连贯的开释
慢查问
show variables like '%slow%';
+---------------------------+----------------------------------------------+
| Variable_name | Value |
+---------------------------+----------------------------------------------+
| slow_launch_time | 2 |
| slow_query_log | On |
+---------------------------+----------------------------------------------+
线程详情
## 查看每个线程的详细信息
SHOW PROCESSLIST;
+--------+----------+------------------+--------------+---------+-------+-------------+------------------+
| Id | User | Host | db | Command | Time | State | Info |
+--------+----------+------------------+--------------+---------+-------+-------------+------------------+
| 3 | xxxadmin | localhost | NULL | Sleep | 1 | cleaning up | NULL |
| 4 | xxxadmin | localhost | NULL | Sleep | 0 | cleaning up | NULL |
| 5 | xxxadmin | localhost | NULL | Sleep | 6 | cleaning up | NULL |
+--------+----------+------------------+--------------+---------+-------+-------------+------------------+
总结
当然,以上只是一个大略的解决思路,无论应用哪一种形式,都须要结合实际业务场景去扩容。
另外,对于生产环境,设置失当的告警阈值,也是很有必要的。
最初,在编程时,因为用 MySQL 语句调用数据库执行SQL
,会调配一个线程操作 MySQL,所以在完结调用后,须要回收连贯,防止透露。
参考文章
https://dev.mysql.com/doc/ref…
https://dev.mysql.com/doc/ref…
https://dev.mysql.com/doc/ref…
MySQL Calculator