python - deploy - Problema de truncamiento de Nginx+fastcgi

nginx python 3

Question

Estoy ejecutando un sitio de Django usando la interfaz de fastcgi para nginx. Sin embargo, algunas páginas se sirven truncadas (es decir, el origen de la página simplemente se detiene, a veces en el medio de una etiqueta). Cómo soluciono esto (déjame saber qué información adicional es necesaria y la publicaré)

Detalles:

Estoy usando flup y generando el servidor fastcgi con el siguiente comando:

python ./manage.py runfcgi umask=000 maxchildren=5 maxspare=1 minspare=0 method=prefork socket=/path/to/runfiles/django.sock pidfile=/path/to/runfiles/django.pid

La configuración de nginx es la siguiente:

# search and replace this: {project_location}
pid /path/to/runfiles/nginx.pid;
worker_processes  2;
error_log /path/to/runfiles/error_log;
events {
    worker_connections  1024;
    use epoll;
}
http {
    # default nginx location
    include        /etc/nginx/mime.types;
    default_type    application/octet-stream;
    log_format main
        ''$remote_addr - $remote_user [$time_local] ''
            ''"$request" $status $bytes_sent ''
        ''"$http_referer" "$http_user_agent" ''
        ''"$gzip_ratio"'';
    client_header_timeout  3m;
    client_body_timeout    3m;
    send_timeout           3m;
    connection_pool_size        256;
    client_header_buffer_size    1k;
    large_client_header_buffers    4 2k;
    request_pool_size        4k;
    output_buffers   4 32k;
    postpone_output  1460;
    sendfile        on;
    tcp_nopush             on;
    keepalive_timeout      75 20;
    tcp_nodelay            on;
    client_max_body_size       10m;
    client_body_buffer_size    256k;
    proxy_connect_timeout      90;
    proxy_send_timeout         90;
    proxy_read_timeout         90;
    client_body_temp_path      /path/to/runfiles/client_body_temp;
    proxy_temp_path            /path/to/runfiles/proxy_temp;
    fastcgi_temp_path            /path/to/runfiles/fastcgi_temp;
    gzip on;
    gzip_min_length  1100;
    gzip_buffers     4 32k;
    gzip_types       text/plain text/html application/x-javascript text/xml text/css;
    ignore_invalid_headers    on;
    server {
        listen 80;
        server_name alpha2.sonyalabs.com;
        index index.html;
        root   /path/to/django-root/static;
        # static resources
        location ~* ^/static/.*$
        {
        root   /path/to/django-root;
                expires 30d;
                break;
        }
        location / {
            # host and port to fastcgi server
            fastcgi_pass unix:/path/to/runfiles/django.sock;
            fastcgi_param PATH_INFO $fastcgi_script_name;
            fastcgi_param REQUEST_METHOD $request_method;
            fastcgi_param QUERY_STRING $query_string;
            fastcgi_param CONTENT_TYPE $content_type;
            fastcgi_param CONTENT_LENGTH $content_length;
            fastcgi_pass_header Authorization;
            fastcgi_intercept_errors off;
        }
        location /403.html {
                root   /usr/local/nginx;
                access_log   off;
        }
        location /401.html {
                root   /usr/local/nginx;
                access_log   off;
        }
        location /404.html {
                root   /usr/local/nginx;
                access_log   off;
        }
        location = /_.gif {
                    empty_gif;
                access_log   off;
        }
            access_log    /path/to/runfiles/localhost.access_log main;
            error_log    /path/to/runfiles/localhost.error_log;
        }
}

Answer 1

FastCGI no tiene la culpa de esto.

Me encontré con exactamente el mismo problema usando nginx / gunicorn. Reducir el tamaño de la respuesta a menos de 32k (en el caso específico usando la etiqueta spaceless espacio en la plantilla) lo resolvió.

Como dice dwc, probablemente sea un límite difícil debido a la forma en que nginx usa el espacio de direcciones.

Answer 2

Qué interfaz de fastcgi estás usando y cómo. ¿Es flup? En caso afirmativo, pega la forma en que engendras el servidor y cómo está enganchado en nginx. Sin esa información, es solo adivinar qué podría salir mal.

Posibles problemas:

• nginx tiene errores. Al menos lighttpd tiene horribles errores fastcgi, no me gustaría si nginx también tiene algo :)
• Django está muriendo con un rastreo en un sistema interno que no está apropiadamente atrapado y cierra el servidor fastcgi que no se puede ver desde el cliente. En esa situación envuelva la llamada de la aplicación del servidor fastcgi y pruebe / excepto para imprimir la excepción.

Pero el registro y la configuración del servidor serían geniales.

Answer 3

intentar subir "gzip_buffers" puede ayudar.

mira aquí: http://blog.leetsoft.com/2007/7/25/nginx-gzip-ssl

Answer 4

Estoy ejecutando configuraciones muy similares a esta, tanto en mi servidor web (Webfaction) como en un servidor local de desarrollo de Ubuntu y no veo ningún problema. Supongo que es un tiempo de espera o un búfer completo que está causando esto.

¿Puedes publicar el resultado del registro de errores de nginx? ¿Qué versión de nginx estás usando?

Como nota al margen, puede valer la pena examinar django-logging para descubrir qué está haciendo su proceso fastcgi.

Answer 5

Verifique los registros de errores para ver si hay errores de "Permiso denegado" en los archivos .../nginx/tmp/... Nginx funcionará bien a menos que necesite espacio temporal, y eso normalmente ocurre en límites de 32 K. Si encuentra estos errores, asegúrese de que el directorio tmp sea editable por el usuario que nginx ejecuta como.

Answer 6

Tuve el mismo problema al ejecutar Nagios en nginx. Me encontré con tu pregunta mientras busqué una respuesta en Google, y al leer las respuestas relacionadas con el "permiso denegado" me llamó la atención (y tal vez te ayude):

• Nginx error.log estaba informando:

  2011/03/07 11:36:02 [crit] 30977 # 0: * 225952 open () "/ var / lib / nginx / fastcgi / 2/65/0000002652" failed (13: Permiso denegado)

• así que acabo de ejecutar # chown -R www-data: www-data / var / lib / nginx / fastcgi

• Arreglado (y gracias por su ayuda indirecta)