通过MYSQL.sock在高负载下PHP/MYSQL连接失败


PHP / MYSQL connection failures under heavy load through mysql.sock

在问这个问题之前,我已经读了很多书,所以让我在前言中说,我没有耗尽连接、内存或cpu,据我所知,我也没有耗尽文件描述符。

以下是PHP在MySQL负载过重时向我抛出的内容:

无法通过套接字'/var/lib/MySQL/MySQL.sock'连接到本地MySQL服务器(11"资源暂时不可用")

这种情况在负载下随机发生,但我推得越多,php就越频繁地向我抛出这种情况。当这种情况发生时,我总是可以通过控制台进行本地连接,并从php连接到127.0.0.1,而不是使用更快的unix套接字的"localhost"。

以下是一些系统变量来排除常见问题:

cat /proc/sys/fs/file-max = 4895952
lsof | wc -l = 215778 (during "outages")

可用连接的最高使用率:26%(261/1000)

InnoDB缓冲池/数据大小:10.0G/3.7G(充足的空间)

  • 软nofile 999999
  • 硬盘文件999999

我实际上正在运行MariaDB(服务器版本:10.0.17-MariaDB-MariaDB-Server)

这些结果是在正常负载下生成的,也是在非工作时间运行mysqlslap生成的,因此,慢速查询不是问题,只是高连接。

有什么建议吗?如果需要,我可以报告额外的设置/数据-mysqltuner.pl说一切正常

同样,这里揭示的是,通过IP连接在这些停机期间运行良好且速度快——我只是不明白为什么。

编辑:这是我的my.ini(从我最近的故障排除更改中,有些值可能有点高,请记住MySQL日志、系统日志或dmesg中没有错误)

socket=/var/lib/mysql/mysql.sock
skip-external-locking
skip-name-resolve
table_open_cache=8092
thread_cache_size=16
back_log=3000
max_connect_errors=10000
interactive_timeout=3600
wait_timeout=600                                                                                            
max_connections=1000
max_allowed_packet=16M
tmp_table_size=64M
max_heap_table_size=64M
sort_buffer_size=1M
read_buffer_size=1M
read_rnd_buffer_size=8M
join_buffer_size=1M
innodb_log_file_size=256M
innodb_log_buffer_size=8M
innodb_buffer_pool_size=10G
[mysql.server]
user=mysql
[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
open-files-limit=65535

很可能是由于net.core.somaxconn/proc/sys/net/core/somaxconn 的价值是多少

net.core.somaxconn 
# The maximum number of "backlogged sockets".  Default is 128.

队列中尚未连接的连接。任何超过该队列的东西都将被拒绝。我怀疑这是你的案子。试着根据你的负荷增加它。

作为根用户运行

echo 1024 > /proc/sys/net/core/somaxconn 

这是可以也应该通过分析来解决的问题。学习如何做到这一点是一项很好的技能。

分析,找出在沉重的负载下发生了什么。。。查询的数量,执行时间应该是您的第一步。确定负载,然后进行正确的数据库配置设置。您可能会发现您需要优化sql查询!

然后确保PHP数据库驱动程序设置也一致,以充分利用数据库连接。

以下是MariaDB线程池文档的链接。我知道它说的是5.5版本,但它仍然很相关,页面确实参考了10版本。列出的一些设置可能不在您可以使用的.cnf文件中。

https://mariadb.com/kb/en/mariadb/threadpool-in-55/

从我的脑海中,我可以认为max_connections可能是问题的根源。我会提高限制,至少消除这种可能性。

希望能有所帮助。