主页 / server / 问题 / 892986
Accepted
BurninLeo
Asked: 2018-01-20 00:05:19 +0800 CST

告诉 nginx 在随机“502 Bad Gateway”上使用不同的 PHP 进程

  • 772

在网络服务器上，通常可以很好地与nginxand php-fpm（当前版本 7.0.22，但这主要与版本无关），有时会发生 502 Bad Gateway。这通常意味着：其中一个php-fpm进程已经崩溃，并且nginx没有收到来自所选进程的答复。

我目前的解决方法是不仅要监视php-fpm进程，还要监视 PHP 页面的输出。如果这在 4 分钟内不起作用（两次失败的重试，监视间隔为 2 分钟），monit则将终止所有php-fpm进程并重新启动php-fpm服务。有效，但仍会导致 5 分钟的停机时间（至少对于连接到损坏进程的某些用户而言）或更长时间，因为monit在它观察到 502 Bad Gateway 之前，不妨从一个健全的进程中看到几次答案。

(1) 理想的解决方案是修复任何破坏php-fpm进程的错误。然而，这个错误很少发生，所以我无法找到一些具体的原因。可能是 PHP 脚本中的内存泄漏……我不知道。

(2) 我认为，第二好的选择将涉及来自 的一些合作nginx。如果 webserver 进程可以对 PHP 故障做出反应，它可以 (a) 杀死特别损坏的进程并 (b) 尝试另一个进程，而不是抛出 502 Bad Gatway。

到目前为止，我还没有找到nginx对失败做出反应的选项。谁知道如何实现这一目标？还是有更简单的解决方案，我错过了？

connect() to unix:/run/php/php7.0-fpm.sock failed (11: Resource temporarily unavailable)
ubuntu

1 个回答

  1. Best Answer

    您不能将请求从一个进程移动到同一上游内的另一个进程，但您可以将其从一个上游移动到另一个。

    首先，您至少需要两个上游（您将需要两个不同的 php 池）： 

    upstream yourproject {
    server unix:/run/php/php7.0-fpm_primary.sock;
    server unix:/run/php/php7.0-fpm_secondary.sock;
}

    然后您可以配置它们之间的故障转移： 

    location ~ \.php$ {
    # First, you need to capture fastcgi errors
    fastcgi_intercept_errors      on;

    # Specifies in which cases a request should be passed to the next server
    fastcgi_next_upstream         error timeout http_500 http_503;

    # Limits the time during which a request can be passed
    # to the next server
    fastcgi_next_upstream_timeout 10s;

    # Limits the number of possible tries for passing
    # a request to the next server
    fastcgi_next_upstream_tries   2;

    fastcgi_pass yourproject;
}

    但这不会解决您的问题，因为您将在同一台服务器之间进行故障转移。

    我建议你：

    1. 使用 TCP 套接字代替 UNIX 套接字，它们对于高并发更加可靠和稳定：

      upstream yourproject {
    server 127.0.0.1:9000;
}

      您显然已将您的 php 指向您的 php 池配置中的这个 TCP 套接字（listen = 127.0.0.1:9000）

    2. 增加进程和 fd 限制/etc/limits.conf：

      *    soft    nofile    65536
*    hard    nofile    65536
*    hard    nproc     65536
*    soft    nproc     65536

    3. 增加net.core.somaxconn和net.core.netdev_max_backlog中/etc/sysctl.conf。也许你已经达到了极限。

    4. 如果您pm = dynamic在 PHP 配置池中使用，请检查此参数并根据文档和系统资源进行调整：pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers. 也许你也达到了极限。

    5. 增加pm.max_requests您的 PHP 配置以避免重生过程过于频繁地发生。

    如果这不起作用，请复制并粘贴您的 PHP 和 Nginx 配置文件，以更深入地了解它们。

    • 1

相关问题