Nginx / FastCGI все время рушится на меня - PullRequest
Новая
       13

Nginx / FastCGI все время рушится на меня

0 голосов
/ 12 января 2012

Есть ли какие-нибудь гуру Nginx / FastCGI, которые могут мне помочь?

Я использую nginx 1.0.11 на Debian Squeeze, обслуживающей Mono FastCGI (fastcgi-mono-server4 2.10.2.0). Я заметил, что экземпляры FastCGI часто дают сбой в ответ на запросы POST, превышающие ~ 350 000 байтов. Хотя некоторые запросы такого масштаба являются успешными, они с большей вероятностью потерпят неудачу при увеличении трафика. Кроме того, часто при сбое экземпляра FastCGI рабочий процесс Nginx будет зомбирован (т.е. Nginx по-прежнему обрабатывает запросы, но время ожидания истекло - 502 не возвращаются, хотя все шлюзы могут быть недоступны). Перед включением рабочего процесса и экземпляра FastCGI я включил отладку Nginx и заметил следующее. 

2012/01/11 20:38:42 [debug] 1744#0: *141 writev: 8
2012/01/11 20:38:42 [debug] 1744#0: *141 sendfile: @360448 32768
2012/01/11 20:38:42 [debug] 1744#0: *141 sendfile: 32768, @360448 32768:32768
2012/01/11 20:38:42 [debug] 1744#0: *141 writev: 8
2012/01/11 20:38:42 [debug] 1744#0: *141 sendfile: @393216 12167
2012/01/11 20:38:42 [debug] 1744#0: *141 sendfile: 12167, @393216 12167:12167
2012/01/11 20:38:42 [debug] 1744#0: *141 writev: 9
2012/01/11 20:38:42 [debug] 1744#0: *141 chain writer out: 0000000000000000
2012/01/11 20:38:42 [debug] 1744#0: *141 event timer del: 16: 1326314382071
2012/01/11 20:38:42 [debug] 1744#0: *141 event timer add: 16: 60000:1326314382072

Это только последние 10 записей в журнале, но, если вы хотите увидеть больше, я, конечно, могу написать или в личку. И, наконец, вот мой конфигурационный файл Nginx. 

user                 www-data;
worker_processes     2;
worker_rlimit_nofile 8192;
events {
    worker_connections  2048;
    use                 epoll;
}

http {
    error_log               /var/log/error.log;
    include                 mime.types;
    default_type            application/octet-stream;           
    sendfile                on;
    keepalive_timeout       65;

    gzip              on;
    gzip_http_version 1.1;
    gzip_vary         on;
    gzip_comp_level   6;
    gzip_proxied      any;
    gzip_types        text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript text/x-js font/opentype application/font-woff;
    gzip_buffers      16 8k;
    gzip_disable      "MSIE [1-6]\.(?!.*SV1)";

    upstream backend {
        server 127.0.0.1:8080;
        server 127.0.0.1:8081;
    }

    server {
        listen       80;
        server_name  my_server;
        root         /var/www;
        access_log   /var/log/host.access.log;

        location / {
            fastcgi_param            SCRIPT_FILENAME /scripts$fastcgi_script_name;
            include                  fastcgi_params;
            fastcgi_pass             backend;
            fastcgi_next_upstream    http_500 http_404 error timeout;
            fastcgi_read_timeout     60;
        }

        location ~* ^.+\.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|pdf|txt|tar|wav|bmp|rtf|js|flv|swf|html|htm)$ {
            root /var/www;
        }
    }
}

1 Ответ

0 голосов
/ 11 мая 2012

Оказывается, Моно LOH и отсутствие его дефрагментации было проблемой. Таким образом, это решение заключалось в том, чтобы бросить больше памяти на проблему.

http://blog.mohammadjalloul.com/blogs/mo/archive/2010/02/21/the-large-object-heap.aspx

...