0%

记录-修改Mysql最大连接数

Pre:

之前常遇到mysql gone away这类错误,由于用的是sqlalchemy里的Null Pool.即不使用连接池。

按道理来说,要选用连接池的,但由于还没找到sqlalchemy连接池与celery多进程的最佳实践,故暂时搁置这个方案…

这样的话,每次在执行sql语句的时候,都会跟数据库建立链接,执行结束后,再释放连接.

这样在高并发的情况下会频繁连接数据库,占用很多连接数.

所以这个时候要适当增大mysql的最大连接数.


查询:

查询最大连接数

show variables like '%max_connections%';

历史最大连接数量

show global status like 'Max_used_connections';


修改最大连接数:

修改mysql配置文件:

环境:Centos7

1
vi /etc/my.cnf
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
[mysqld]
#
# Remove leading # and set to the amount of RAM for the most important data
# cache in MySQL. Start at 70% of total RAM for dedicated server, else 10%.
# innodb_buffer_pool_size = 128M
#
# Remove leading # to turn on a very important data integrity option: logging
# changes to the binary log between backups.
# log_bin
#
# Remove leading # to set options mainly useful for reporting servers.
# The server defaults are faster for transactions and fast SELECTs.
# Adjust sizes as needed, experiment to find the optimal values.
# join_buffer_size = 128M
# sort_buffer_size = 2M
# read_rnd_buffer_size = 2M
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock

port=33066

max_connections=500
max_allowed_packet = 512M
#query_cache_limit = 4M
wait_timeout = 288000
interactive_timeout = 288000
read_buffer_size = 16M

# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0

# Recommended in standard MySQL setup
sql_mode=STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

第一次只修改了配置文件,也没有及时验证有无修改成功.才发现改了配置文件还不够,还需要继续往下修改.


配置limits.conf:

1
2
3
4
vi /etc/security/limits.conf
# 添加mysql用户配置
mysql hard nofile 65535
mysql soft nofile 65535

配置mariadb.service:

1
2
3
vi /usr/lib/systemd/system/mysqld.service
# 添加参数
LimitNOFILE=65535

重启

1
systemctl daemon-reload
1
2
# 重启mysql
service mysqld restart

总结:

之前在解决类似的数据库错误的时候,确实是比较难定位到具体的原因.

PostgreSQL Connection Timed Out OperationalError on Django and new server

连接超时错误表明无法通过网络上的设置访问数据库服务器,其方式不会立即返回错误。

根据我的经验,最好的方法是分别对连接的两侧进行故障排除。这意味着首先从psql命令行测试连接的服务器端,然后在解析后测试django端。

最好的方法是对涉及到组件(元素)一一去排查原因,不要一直想当然的陷入到代码里.那样会只见树不见林…


refs: