Problem z obcięciem Nginx + fastcgi

Question

Używam strony Django używając interfejsu fastcgi do nginx. Jednak niektóre strony są wyświetlane jako obcięte (tzn. Źródło strony po prostu się zatrzymuje, czasami w środku znacznika). Jak mogę rozwiązać ten problem (daj mi znać, jakie dodatkowe informacje są potrzebne, a ja go zakładać)

Szczegóły:

Używam flup i tarła serwera fastcgi za pomocą następującego polecenia:

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 config wygląda następująco:

# 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

interfejs Co FastCGI używasz iw jaki sposób. Czy to jest flup? Jeśli tak, wklej sposób, w jaki spawnujesz serwer i jak jest on podłączony do nginx. Bez tych informacji to tylko zgadywanie, co może pójść nie tak.

Możliwe problemy:

• nginx jest wadliwy. Przynajmniej lighttpd ma okropne błędy fastcgi, nie zastanawiałbym się, czy nginx też je ma :)
• Django umiera z powrotem w systemie wewnętrznym, który nie jest poprawnie przechwycony i zamyka serwer fastcgi, którego nie można zobaczyć z Klient. W tej sytuacji zamknij wywołanie aplikacji serwera fastcgi i spróbuj/oprócz tego, aby wydrukować wyjątek.

Ale log serwera i config byłoby świetnie.

Answer 2

spróbuj podnieść "gzip_buffers" może pomóc.

zobaczyć tutaj: http://blog.leetsoft.com/2007/7/25/nginx-gzip-ssl

Answer 3

biegnę bardzo podobną konfigurację do tego zarówno na moją witryną (Webfaction) i na lokalnym serwerze dev Ubuntu i nie widzę żadnych problemów. Zgaduję, że to jest czasowy lub pełny bufor, który to powoduje.

Czy można opublikować wyjście dziennika błędów nginx? Jakiej wersji nginxu używasz?

Na marginesie warto spojrzeć na numer django-logging, aby dowiedzieć się, co robi proces fastcgi.

Answer 4

Sprawdź dzienniki błędów pod kątem błędów "Odmówiono uprawnień" zapisanych w plikach .../nginx/tmp/.... Nginx działa dobrze, chyba że potrzebuje tymczasowej przestrzeni, a to zwykle dzieje się na granicach 32K. Jeśli znajdziesz te błędy, upewnij się, że katalog tmp jest zapisywalny przez użytkownika nginx działa jako.

Answer 5

Miałem dokładnie ten sam problem z uruchomieniem Nagios na nginx. Natknąłem się na swoje pytanie podczas googlowania na odpowiedź, i czytając „brak dostępu” Related odpowiedzi uderzyło mnie (i być może to pomoże):

• błąd Nginx.log zgłaszał:

  2011/03/07 11:36:02 [crit] 30977 # 0: * 225952 open() "/ var/lib/nginx/fastcgi/2/65/0000002652" nie powiodło się (13: Permission denied)

• więc po prostu zabrakło # chown -R www-data: www-data/var/lib/nginx/FastCGI

• Poprawiono! (i dziękuję za pomoc pośrednią)

Answer 6

FastCGI nie ponosi winy za to.

Wpadłem na dokładnie ten sam problem, używając nginx/gunicorn. Zmniejszenie rozmiaru odpowiedzi do mniej niż 32k (w konkretnym przypadku przy użyciu znacznika spaceless w szablonie) rozwiązało problem.

Jak mówi DWC, jest to prawdopodobnie trudny limit ze względu na sposób, w jaki nginx używa przestrzeni adresowej.