mysql - 带有 mysqlnd 的 PHP-FPM 卡在连接上并且没有超时(内部 gdb 回溯)

Question

我正在运行 PHP-FPM，在负载极高时遇到一个问题，导致 php 进程永远卡住。我对卡住的正在运行的进程进行了 GDB 回溯，得到了这个(删除了不相关的帧):

#0  0x00007ff51704bb90 in __poll_nocancel () at ../sysdeps/unix/syscall-template.S:81

#1  0x0000000000694694 in poll (__timeout=<optimized out>, __nfds=1, __fds=0x7fff18a2c800) at /usr/include/x86_64-linux-gnu/bits/poll2.h:46

#2  php_pollfd_for (timeouttv=0x2c18a30, events=25, fd=<optimized out>) at /build/buildd/php5-5.5.19+dfsg/main/php_network.h:165

#3  php_sock_stream_wait_for_data (stream=0x2df2b88, sock=0x2c18a28) at /build/buildd/php5-5.5.19+dfsg/main/streams/xp_socket.c:131

#4  php_sockop_read (stream=0x2df2b88, buf=0x2e03628 "X\221\340\002", count=4) at /build/buildd/php5-5.5.19+dfsg/main/streams/xp_socket.c:154

#5  0x00000000004a629a in php_openssl_sockop_read (stream=0x2df2b88, buf=0x2e03628 "X\221\340\002", count=<optimized out>) at /build/buildd/php5-5.5.19+dfsg/ext/openssl/xp_ssl.c:234

#6  0x0000000000688926 in _php_stream_fill_read_buffer (stream=stream@entry=0x2df2b88, size=size@entry=4) at /build/buildd/php5-5.5.19+dfsg/main/streams/streams.c:691

#7  0x0000000000688a87 in _php_stream_read (stream=stream@entry=0x2df2b88, buf=buf@entry=0x7fff18a2c9e0 "", size=size@entry=4) at /build/buildd/php5-5.5.19+dfsg/main/streams/streams.c:738

#8  0x00007ff5164b83a6 in php_mysqlnd_net_network_read_ex_pub (net=<optimized out>, buffer=<optimized out>, count=4, stats=0x2add010, error_info=<optimized out>)
    at /build/buildd/php5-5.5.19+dfsg/ext/mysqlnd/mysqlnd_net.c:80

#9  0x00007ff5164b7cb6 in php_mysqlnd_net_receive_ex_pub (net=0x2e04238, buffer=0x7fff18a2c9e0 "", count=4, conn_stats=0x2add010, error_info=0x2e13860)
    at /build/buildd/php5-5.5.19+dfsg/ext/mysqlnd/mysqlnd_net.c:682

#10 0x00007ff5164b118b in mysqlnd_read_header (net=0x2e04238, conn_stats=0x2add010, error_info=<optimized out>, header=<optimized out>, header=<optimized out>)
    at /build/buildd/php5-5.5.19+dfsg/ext/mysqlnd/mysqlnd_wireprotocol.c:287

#11 0x00007ff5164b1d46 in php_mysqlnd_greet_read (_packet=0x2e14e98, conn=0x2e13728) at /build/buildd/php5-5.5.19+dfsg/ext/mysqlnd/mysqlnd_wireprotocol.c:333

#12 0x00007ff5164ab8ad in php_mysqlnd_conn_data_connect_handshake_pub (conn=0x2e13728, host=<optimized out>, user=0x2b49d70 "testuser", passwd=0x2b49c40 "<PASSWORD REMOVED>", passwd_len=7, db=0x2b43c18 "testuser",
    db_len=7, mysql_flags=959117) at /build/buildd/php5-5.5.19+dfsg/ext/mysqlnd/mysqlnd.c:774

#13 0x00007ff5164a9e71 in php_mysqlnd_conn_data_connect_pub (conn=0x2e13728, host=0x2e13558 "localhost", user=0x2b49d70 "testuser",
    passwd=0x2b49c40 "<PASSWORD REMOVED>", passwd_len=7, db=0x2b43c18 "testuser", db_len=7, port=3306, socket_or_pipe=0x7ff50a563b4c "/var/run/mysqld/mysqld.sock", mysql_flags=959117)
    at /build/buildd/php5-5.5.19+dfsg/ext/mysqlnd/mysqlnd.c:958

#14 0x00007ff5164a6430 in php_mysqlnd_conn_connect_pub (conn_handle=0x2e136d8, host=0x2e13558 "localhost", user=0x2b49d70 "testuser",
    passwd=0x2b49c40 "<PASSWORD REMOVED>", passwd_len=7, db=0x2b43c18 "testuser", db_len=7, port=3306, socket_or_pipe=0x7ff50a563b4c "/var/run/mysqld/mysqld.sock", mysql_flags=131072)
    at /build/buildd/php5-5.5.19+dfsg/ext/mysqlnd/mysqlnd.c:1098

#15 0x00007ff5164adc07 in mysqlnd_connect (conn_handle=0x2e136d8, host=<optimized out>, user=<optimized out>, passwd=<optimized out>, passwd_len=<optimized out>, db=<optimized out>, db_len=7, port=3306,
    socket_or_pipe=0x7ff50a563b4c "/var/run/mysqld/mysqld.sock", mysql_flags=131072) at /build/buildd/php5-5.5.19+dfsg/ext/mysqlnd/mysqlnd.c:1131

#16 0x00007ff50a55fe82 in mysqli_common_connect (ht=<optimized out>, return_value=0x2e05978, return_value_ptr=<optimized out>, this_ptr=<optimized out>, return_value_used=<optimized out>,
    is_real_connect=is_real_connect@entry=0 '\000', in_ctor=in_ctor@entry=1 '\001') at /build/buildd/php5-5.5.19+dfsg/ext/mysqli/mysqli_nonapi.c:242

#17 0x00007ff50a560633 in zif_mysqli_link_construct (ht=<optimized out>, return_value=<optimized out>, return_value_ptr=<optimized out>, this_ptr=<optimized out>, return_value_used=<optimized out>)
    at /build/buildd/php5-5.5.19+dfsg/ext/mysqli/mysqli_nonapi.c:320

所以我看到的是我正在尝试连接到 MySQL，然后 PHP 在轮询套接字时卡住了。 MySQL 可能会丢弃或拒绝连接(数据库的 CPU 负载为 100%)。

但是，我将 mysql.connect_timeout 设置为 60，所以我预计连接不会持续这么久(已经超过 20 分钟)。 default_socket_timeout 也设置为 300 秒。

我会先发制人，说我已经尝试过(我们使用的是 DBAL)，并且遇到了与 mysqli 在后台使用相同连接函数的问题相同的升级到 mysqli 的任何建议。

我在 Ubuntu 上运行 PHP 5.5.19，并使用 mysqlnd 驱动程序。

知道什么会导致 PHP 不超时吗？

Answer 1

我认为您正在达到我所说的“死可用性范围”。这意味着你陷入了让你的行动完全失败(它会超时的地方)和但也没有发挥作用之间。所以事物的链条是这样的

1. 你调用你的 PHP 脚本
2. PHP 尝试打开与 MySQL 的连接
3. MySQL(在 100% 负载下)响应缓慢，但会在分配的超时时间内打开连接
4. PHP 发送 SQL
5. MySQL(仍处于 100% 负载)现在可能卡住了。查询最终会执行，但现在您遇到了实际返回响应的问题。所以 PHP 得到...一些东西。说个涓涓细流。 MySQL 不会超时(它有一个正在响应的有效请求)，PHP 也不会(它以极慢的速度获取数据)。因此，这两个程序都陷入了这个“死区”，其中发生的事情足以避免超时，但还不足以解决死锁。有时您可以在执行 SHOW PROCESSLIST;
时看到这一点

我知道您没有发送 SQL，但我认为相同的原则会起作用。您有时会看到这种情况发生在使用 MySQL Workbench 的远程数据库中(其中执行查询但无法返回结果)。因此，Workbench 挂断了等待实际上永远不会发生的响应。

那么如何解决这个问题呢？实际上，您无法达到 PHP 的编程级别。 PHP API 没有公开足够多的底层调用，无法让您认识到自己陷入死区并终止连接。编写一个寻找死区的脚本总是会冒着终止其他良好进程的风险。你最好的选择(尽管我不想这么说)是加强你的 MySQL 并确保它有足够的资源不会达到 100%。如果您正在与 PHP/Apache 共享服务器，那么这就是此类事情的秘诀。我注意到自从我们将 MySQL 移动到它自己的实例后，它很少发生在我们更大更好的系统上。另外，查看 mysqltuner .它可以查看您的 MySQL 实例并建议配置调整以提高性能。