Linux

Nginx 和 gunicorn 沒有顯示整個頁面(記憶體問題)

  • April 21, 2015

我有一個 django 應用程序,它在 django 的伺服器上執行良好。我剛剛將其配置為與 nginx 和 gunicorn 一起使用。除了其中一個之外,幾乎每個頁面都可以正常工作。這是一個相當大的頁面,由 4 個選擇(下拉)菜單組成,每個菜單有 1000 個條目,所有這些都由 guinicorn 的單個 html 文件發送。Gunicorn 只顯示頁面的一半。同樣有趣的是,沒有 nginx,gunicorn 可以很好地顯示整個內容。儘管生成的頁面不是靜態的,但由於某種原因,nginx 會破壞頁面。

這是我的nginx配置:

ec2-user@ip-172-31-44-39:~/mira_website> sudo cat /etc/nginx/sites-available/miraFrontEnd
# This is example contains the bare minimum to get nginx going with
# Gunicornservers.

worker_processes 1;


user ec2-user nogroup; # for systems with a "nogroup"
# user nobody nobody; # for systems with "nobody" as a group instead

# Feel free to change all paths to suit your needs here, of course
pid /tmp/nginx.pid;
error_log /tmp/nginx.error.log;

events {
 worker_connections 1024; # increase if you have lots of clients
 accept_mutex off; # "on" if nginx worker_processes > 1
 # use epoll; # enable for Linux 2.6+
 # use kqueue; # enable for FreeBSD, OSX
}

http {
 # nginx will find this file in the config directory set at nginx build time
#  include mime.types;

 # fallback in case we can't determine a type
 default_type application/octet-stream;

 # click tracking!
 access_log /tmp/nginx.access.log combined;

 # you generally want to serve static files with nginx since neither
 # Unicorn nor Rainbows! is optimized for it at the moment
 sendfile on;

 tcp_nopush on; # off may be better for *some* Comet/long-poll stuff
 tcp_nodelay off; # on may be better for some Comet/long-poll stuff

 gzip on;
 gzip_http_version 1.0;
 gzip_proxied any;
 gzip_min_length 500;
 gzip_disable "MSIE [1-6]\.";
 gzip_types text/plain text/html text/xml text/css
            text/comma-separated-values
            text/javascript application/x-javascript
            application/atom+xml;

 upstream app_server {

   # for UNIX domain socket setups:
   server unix:/home/ec2-user/gunicorn.sock fail_timeout=0;

   # for TCP setups, point these to your backend servers
   # server 192.168.0.7:8080 fail_timeout=0;
   # server 192.168.0.8:8080 fail_timeout=0;
   # server 192.168.0.9:8080 fail_timeout=0;
 }

 server {
   # listen 80 default deferred; # for Linux
   # listen 80 default accept_filter=httpready; # for FreeBSD
   listen 8000;

   client_max_body_size 4G;
   server_name _;

   keepalive_timeout 10;


   location /static {
       autoindex on;
       alias /home/ec2-user/mira_website/manageDb/static/;
   }

   location / {
     # checks for static file, if not found proxy to app
     try_files $uri @proxy_to_app;
   }

   location @proxy_to_app {
     # an HTTP header important enough to have its own Wikipedia entry:
     #   http://en.wikipedia.org/wiki/X-Forwarded-For
     proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

     # enable this if and only if you use HTTPS, this helps Rack
     # set the proper protocol for doing redirects:
     # proxy_set_header X-Forwarded-Proto https;

     # pass the Host: header from the client right along so redirects
     # can be set properly within the Rack application
     proxy_set_header Host $http_host;

     # we don't want nginx trying to do something clever with
     # redirects, we set the Host: header above already.
     proxy_redirect off;

     proxy_pass http://app_server;

   }

   # Error pages
   error_page 500 502 503 504 /500.html;
   location = /500.html {
     root /path/to/app/current/public;
   }
 }
}

該伺服器執行在帶有 Suse linux 的 amazon ec2 上。

有任何想法嗎?

**編輯:**好的,這很有趣,我清除了瀏覽器的記憶體、歷史記錄、cookies 和所有內容,它開始工作了。然後,幾分鐘後再次嘗試後,它遇到了同樣的問題。所以看起來,當我清除記憶體時,它開始工作但只是一段時間(奇怪!)。

我嘗試了很多不同的配置並讓它工作,但我不確定實際情況如何。我認為的情況是名為proxy_buffering. 現在設置為off

此外,可能解決此問題的方法是設置proxy_buffer_size size. 是有關此指令的官方文件。

引用自:https://serverfault.com/questions/683450