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)