Проблема усечения Nginx + fastcgi

Question

Я запускаю сайт Django, используя интерфейс fastcgi для nginx. Однако некоторые страницы обслуживаются усеченными (т. Е. Источник страницы просто останавливается, иногда в середине тега). Как это исправить (дайте мне знать, что дополнительная информация необходима, и я отправлю его)

Детали:

Я использую flup и нерест сервер FastCGI с помощью следующей команды:

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 

Nginx конфигурации выглядит следующим образом:

# 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 интерфейс вы используете и как. Это всплеск? Если да, вставьте способ, которым вы создаете сервер, и как он подключен к nginx. Без этой информации это просто догадывается, что может пойти не так.

Возможные проблемы:

• Nginx глючит. По крайней мере lighttpd имеет ужасные ошибки fastcgi, я бы не задавался вопросом, есть ли у nginx слишком):
• Django умирает с трассировкой во внутренней системе, которая не правильно зацепилась и закрывает сервер fastcgi, который вы не видите из клиент. В этой ситуации завершите вызов приложения сервера fastcgi и попробуйте/кроме него распечатать исключение.

Но серверный журнал и конфигурация были бы замечательными.

Answer 2

попытка поднять «gzip_buffers» может помочь.

посмотреть здесь: http://blog.leetsoft.com/2007/7/25/nginx-gzip-ssl

Answer 3

Я бегу очень похожие конфигурации на это как на моем хостинге (Webfaction) и на локальном сервере Dev Ubuntu, и я не вижу никаких проблем. Я предполагаю, что это тайм-аут или полный буфер, который вызывает это.

Можете ли вы опубликовать вывод журнала ошибок nginx? Также, какую версию nginx вы используете?

В качестве побочного примечания может быть полезно посмотреть django-logging, чтобы узнать, что делает ваш процесс fastcgi.

Answer 4

Проверьте свои журналы ошибок на наличие ошибок «Разрешения на отказ», записывая файлы .../nginx/tmp/.... Nginx будет работать нормально, если ему не требуется временное пространство, и это обычно происходит при границах 32K. Если вы обнаружите эти ошибки, убедитесь, что каталог tmp доступен для записи пользователем nginx.

Answer 5

У меня была такая же точная проблема, что и Nagios на nginx. Я наткнулся на ваш вопрос, а прибегая к помощи для ответа, и чтения «нет прав» связанных ответов он ударил меня (и, возможно, это поможет вам):

• Nginx ошибка.журнал сообщал:

  2011/03/07 11:36:02 [crit] 30977 # 0: * 225952 open() "/ var/lib/nginx/fastcgi/2/65/0000002652" failed (13: Разрешение отказано)

• , так что я просто побежал # Чаун -R WWW-данные: WWW-данные/вар/Библиотека/Nginx/FastCGI

• Исправлено! (и спасибо за вашу косвенную помощь)

Answer 6

FastCGI не виноват в этом.

Я столкнулся с точно такой же проблемой, используя nginx/gunicorn. Уменьшение размера ответа до менее 32 тыс. (В конкретном случае с использованием тега spaceless в шаблоне) решило его.

Как говорит dwc, это, вероятно, жесткий предел из-за того, что nginx использует адресное пространство.