Linux Nginx和php-fpm：无法消除502和504错误

我有一个ubuntu服务器和一个高负载的网站。服务器是：

• 专用于nginx，使用php-fpm（没有apache），mysql位于不同的机器上
• 有8GB的内存
• 每秒获取大约2000个请求

根据

top

命令，每个php fpm进程消耗大约65MB的RAM：

可用内存：

admin@myserver:~$ free -m
             total       used       free     shared    buffers     cached
Mem:          7910       7156        753          0        284       2502
-/+ buffers/cache:       4369       3540
Swap:         8099          0       8099

---

问题

最近，我遇到了很大的性能问题。响应时间非常长，网关超时次数非常多，晚上，当负载增加时，90%的用户只看到“服务器未找到”，而不是网站（我似乎无法重现）

---

日志

我的Nginx错误日志中充满了散播的消息：

2012/07/18 20:36:48 [error] 3451#0: *241904 upstream prematurely closed connection while reading response header from upstream, client: 178.49.30.245, server: example.net, request: request: "GET /readarticle/121430 HTTP/1.1", upstream: "fastcgi://127.0.0.1:9001", host: "example.net", referrer: "http://example.net/articles"

我尝试切换到unix套接字，但仍然出现以下错误：

2012/07/18 19:27:30 [crit] 2275#0: *12334 connect() to unix:/tmp/fastcgi.sock failed (2: No such file or directory) while connecting to upstream, client: 84.
237.189.45, server: example.net, request: "GET /readarticle/121430 HTTP/1.1", upstream: "fastcgi://unix:/tmp/fastcgi.sock:", host: "example.net", referrer: "http
://example.net/articles"

php fpm日志中充满了以下内容：

[18-Jul-2012 19:23:34] WARNING: [pool www] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 32 children, there  are 0 idle, and 75 total children

我曾尝试将给定参数增加到

100

，但似乎仍然不够

---

配置

这是我当前的配置

php fpm

listen = 127.0.0.1:9001
listen.backlog = 4096
pm = dynamic
pm.max_children = 130
pm.start_servers = 40
pm.min_spare_servers = 10
pm.max_spare_servers = 40
pm.max_requests = 100

pm.max_requests = 100

nginx

worker_processes  4;
worker_rlimit_nofile 8192;
worker_priority 0;
worker_cpu_affinity 0001 0010 0100 1000;

error_log  /var/log/nginx_errors.log;

events {
    multi_accept off;
    worker_connections  4096;
}


http {
    include       mime.types;
    default_type  application/octet-stream;

    access_log off;
    sendfile        on;
    keepalive_timeout  65;
    gzip  on;

    # fastcgi parameters
    fastcgi_connect_timeout 120;
    fastcgi_send_timeout 180;
    fastcgi_read_timeout 1000;
    fastcgi_buffer_size 128k;
    fastcgi_buffers 4 256k;
    fastcgi_busy_buffers_size 256k;
    fastcgi_temp_file_write_size 256k;
    fastcgi_intercept_errors on;

    client_max_body_size 128M;

    server {
        server_name example.net;
        root /var/www/example/httpdocs;
        index index.php;
        charset utf-8;
        error_log /var/www/example/nginx_error.log;

        error_page 502 504 = /gateway_timeout.html;

        # rewrite rule
        location / {
            if (!-e $request_filename) {
                rewrite ^(.*)$ /index.php?path=$1 last;
            }
        }
        location ~* \.php {
            fastcgi_pass 127.0.0.1:9001;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            fastcgi_param PATH_INFO $fastcgi_script_name;
            include fastcgi_params;
        }
    }
}

---

如果您能就如何识别问题以及我可以调整哪些参数来解决此问题提供任何建议，我将不胜感激。或者8GB的RAM不足以满足这种负载？

为了回答这个问题：

---

您应该检查您的MySQL服务器。可能是它过载了，或者限制了并行MySQL连接的数量。你应该找到瓶颈。根据上面的屏幕截图，它看起来既不像RAM也不像CPU，很可能是I/O。

-@VBrat

您将来可能想做的事情：

1-增加内存大小

2-使用缓存。请参阅缓存如何加快站点速度

---

3-减少执行的查询数量。

许多问题。在如此繁忙的网站上修复它们仍然是值得的。MySQL可能是目前的根本原因。但从长远来看，你需要做更多的工作

缓存

我看到您的一个错误消息显示了对php上游的get请求。对于这样一个高流量的站点（如您所提到的2000r/s），这看起来不太好。此页面（/readarticle/121430）似乎是一个完全可缓存的页面。首先，可以使用nginx缓存这些页面。退房

php fpm

listen = 127.0.0.1:9001
listen.backlog = 4096
pm = dynamic
pm.max_children = 130
pm.start_servers = 40
pm.min_spare_servers = 10
pm.max_spare_servers = 40
pm.max_requests = 100

pm.max_requests = 100

该值表示一个进程在处理100个请求后将被php fpm主进程终止。php fpm使用该值来对抗第三方内存泄漏。您的站点非常繁忙，速度为2000r/s。您的最大子进程数为130，每个子进程最多只能处理100个请求。这意味着在13000/2000=6.5秒之后，所有这些都将被回收。这太多了（每秒杀死20个进程）。您应该至少从1000开始，并增加该值，只要您没有看到内存泄漏。有人在生产中使用10000

nginx.conf

• 问题1：

      if (!-e $request_filename) {
          rewrite ^(.*)$ /index.php?path=$1 last;
      }
  

  应替换为更高效的try_文件：

      try_files $uri /index.php?path=$uri;
  

如果位置块和正则表达式重写规则匹配，则保存额外的

• 问题2：使用unix套接字将比使用ip节省更多的时间（根据我的经验，大约10-20%）。这就是php fpm将其用作默认值的原因

• 问题3：您可能有兴趣在nginx和phpfpm之间建立keepalive连接。nginx官方网站中给出了一个示例

---

我需要查看您的php.ini设置，我认为这与MySQL无关，因为您可能会遇到套接字错误。另外，这是在一段时间后开始发生的事情，还是在服务器重新启动时立即发生的事情

尝试重新启动php5 fpm守护进程，查看跟踪错误日志时发生的情况

检查php.ini文件以及通常位于/etc/nginx/fastcgi_参数中的所有fastcgi_参数。关于你要做的事情，有很多例子

另外，您是否启用了apc php缓存扩展

在php.ini文件中，如果在lamp堆栈上执行以下操作：

扩展=apc.so
..
apc.enabled=0

从命令行进行一些mysql连接负载测试并查看结果可能不会有什么坏处。

• 为PHP设置APC扩展（检查/配置）
• MySQL-检查配置、索引和慢速查询
• 安装并配置Varnish。这可以缓存页面请求，在减少需要进行的php请求和mysql查询量方面非常有用。使用cookies/ssl可能会很棘手，但除此之外，运行起来并不太困难，也非常值得

---

设置nginx微切也会有所帮助。 这将在几秒钟内提供相同的响应
有一些关于nginx性能的好信息。

---

我个人也这么做了，我很高兴。
我不太确定设置中的细节，但您可能想计算一下您可能会消耗多少内存。一个快速的猜测是，你的130个孩子在65mb时每个都需要8.5千兆（实际上没有为1000/1024问题使用任何大脑，但也不包括其他进程）。首先，我会检查你们是否有足够的内存让所有这些子进程和其他进程一起运行。当然，65mb对于一个网页来说是相当多的内存。我会检查一下为什么web应用程序如此缺乏资源。除此之外，一切都合乎逻辑。502发生在nginx没有及时收到php5 fpm的正确响应时。警告：[pool www]在php5 fpm无法再创建一个clild进程来处理下一个查询时，可能会出现忙的情况。很可能，php fpm进程在MySQL access中被阻止。顺便说一句，它们每个进程只使用12 Mb的物理内存。您应该查看RES。您应该检查您的MySQL服务器。可能是它过载了，或者限制了并行MySQL连接的数量。你应该找到瓶颈。根据