Nginx和php-fpm:无法摆脱502和504错误

Question

我有一个ubuntu服务器和一个相当高的网站.服务器是:

• 专用于nginx,使用php-fpm(没有apache),mysql位于不同的机器上
• 有8 GB的RAM
• 每秒获取大约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

---

问题

最近,我遇到了很大的性能问题.非常大的响应时间,非常多Gateway Timeouts,在晚上,当负载变高时,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 socket,但仍然会遇到这些错误:

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,但它似乎仍然不够.

---

CONFIGS

这是我目前的配置

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

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对于这种负载来说还不够？

Answer 1

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

缓存

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

GET /readarticle/121430

php-fpm

pm.max_requests = 100

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

nginx.conf

• 问题一：

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

  应该用更高效的 try_files 代替：

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

您可以保存额外的if位置块和正则表达式重写规则匹配。

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

• 问题 3：您可能对在 nginx 和 php-fpm 之间设置 keepalive 连接感兴趣。nginx 官方网站给出了一个示例。