I've just now noticed that I'm getting this error in the Nginx log when accessing the app in maintenance mode:
[error] 3395#0: *1052 readv() failed (104: Connection reset by peer) while reading upstream, client: 10.36.204.119, server: stage.example.com, request: "POST /fbcanvas/ HTTP/1.0", upstream: "uwsgi://unix:///tmp/example.sock:", host: "stage.example.com", referrer: "http://apps.facebook.com/example_stage/" I don't know how I missed this before, but it looks like the connection is being closed before the response is sent. I did a bit of a Google search and found this post: http://stackoverflow.com/questions/3970495/nginx-connection-reset-response-from-uwsgi-lost but none of the solutions listed in there worked for me. On Thu, Jan 26, 2012 at 5:04 PM, Guy Knights <[email protected]> wrote: > I hope this is the correct way to reply to this message! Apologies if > I include a lot of extra junk, I wasn't 100% sure how to just respond > to the specific message. Anyway... > > Roberto, please see below for the nginx config for the uWSGI server: > > worker_processes 2; > > worker_rlimit_nofile 30000; > > pid /var/run/nginx.pid; > > events { > worker_connections 10240; > use epoll; > } > > http { > include mime.types; > default_type application/octet-stream; > > log_format main '$http_x_forwarded_for - $remote_user > [$time_local] "$request" ' > '$status $body_bytes_sent "$http_referer" ' > '"$http_user_agent $request_time"'; > > sendfile on; > > client_body_timeout 10; > client_header_timeout 10; > keepalive_timeout 2 5; > send_timeout 10; > > server_tokens off; > > gzip on; > gzip_http_version 1.0; > gzip_vary on; > gzip_buffers 16 8k; > gzip_comp_level 6; > gzip_proxied any; > gzip_types application/octet-stream text/plain text/css > application/x-javascript text/xml application/xml text/javascript > application/json image/x-icon image/bmp; > gzip_disable "MSIE [1-6]\.(?!.*SV1)"; > > index index.html; > > server { > listen 80; > server_name example.com *.example.com; > > error_log /var/log/nginx/error.log; > > location / { > uwsgi_pass unix:///tmp/example.sock; > uwsgi_param HTTP_X_REAL_IP $http_x_forwarded_for; > uwsgi_param HTTP_X_FORWARDED_FOR $proxy_add_x_forwarded_for; > include uwsgi_params; > } > > location /media/ { > alias /opt/django/example/media/; > } > > location /adminmedia/ { > alias > /usr/local/lib/python2.6/dist-packages/django/contrib/admin/media/; > } > > location /nginx_status { > stub_status on; > access_log on; > allow 127.0.0.1; > deny all; > } > } > } > > Here's the config for apache: > > user nginx nginx; > worker_processes 1; > > worker_rlimit_nofile 30000; > > pid /var/run/nginx.pid; > > events { > worker_connections 10240; > use epoll; > } > > http { > include mime.types; > default_type application/octet-stream; > > log_format main '$http_x_forwarded_for - $remote_user > [$time_local] "$request" ' > '$status $body_bytes_sent "$http_referer" ' > '"$http_user_agent $request_time"'; > > sendfile on; > > client_body_timeout 10; > client_header_timeout 10; > keepalive_timeout 2 5; > send_timeout 10; > > server_tokens off; > > gzip on; > gzip_http_version 1.0; > gzip_vary on; > gzip_buffers 16 8k; > gzip_comp_level 6; > gzip_proxied any; > gzip_types application/octet-stream text/plain text/css > application/x-javascript text/xml application/xml text/javascript > application/json image/x-icon image/bmp; > gzip_disable "MSIE [1-6]\.(?!.*SV1)"; > > index index.html; > > upstream django { > server 127.0.0.1:9000; > } > > server { > listen 80; > server_name example.com; > > error_log /var/log/nginx/error.log; > > location / { > proxy_pass http://django; > proxy_redirect off; > > proxy_set_header Host $host; > proxy_set_header X-Real-IP $http_x_forwarded_for; > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; > } > > location /media/ { > alias /opt/django/example/media/; > } > > location /adminmedia/ { > alias > /usr/local/lib/python2.6/dist-packages/django/contrib/admin/media/; > } > > location /nginx_status { > stub_status on; > access_log on; > allow 127.0.0.1; > deny all; > } > } > } > > Here's the Upstart init script we use to start the uWSGI server: > > description "uWSGI server for example" > > env LOGFILE=/var/log/uwsgi/uwsgi.log > env SOCKFILE=/tmp/example.sock > env CODEPATH=/opt/django/example > env SETTINGS=stage > env APPVER=00000 > env MAINT=0 > > start on runlevel [2345] > stop on runlevel [!2345] > > pre-start script > echo $APPVER > /tmp/example-version > echo $MAINT > /tmp/example-maint > end script > > respawn > exec /usr/sbin/uwsgi \ > --socket "$SOCKFILE" \ > --uid django --gid django \ > --chmod-socket \ > --threads 1 --workers 20 \ > --harakiri=60 \ > --harakiri-verbose \ > --max-requests=5000 \ > --logto "$LOGFILE" \ > --pythonpath "$CODEPATH" \ > --master \ > --env DJANGO_SETTINGS_MODULE=example.settings."$SETTINGS" \ > --env MAINTENANCE_MODE="$MAINT" \ > --env VERSION="$APPVER" \ > /opt/django/example.wsgi > > Thanks, > Guy > > On Thu, Jan 26, 2012 at 3:00 AM, <[email protected]> wrote: >> Send uWSGI mailing list submissions to >> [email protected] >> >> To subscribe or unsubscribe via the World Wide Web, visit >> http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi >> or, via email, send a message with subject or body 'help' to >> [email protected] >> >> You can reach the person managing the list at >> [email protected] >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of uWSGI digest..." >> >> >> Today's Topics: >> >> 1. Re: Odd Django app 503 behaviour (Roberto De Ioris) >> 2. Re: emperor mode - logging (Roberto De Ioris) >> 3. Re: emperor mode - logging (Roberto De Ioris) >> 4. static file response time vs memory usage (?ukasz Mierzwa) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Thu, 26 Jan 2012 07:23:49 +0100 (CET) >> From: "Roberto De Ioris" <[email protected]> >> To: "uWSGI developers and users list" <[email protected]> >> Subject: Re: [uWSGI] Odd Django app 503 behaviour >> Message-ID: >> <[email protected]> >> Content-Type: text/plain;charset=iso-8859-1 >> >> >>> Since I posted the message below I've done a bit more investigation >>> and discovered that the response returned when running under uWSGI >>> uses chunked transfer encoding, whereas when I switch back to using >>> apache/mod_wsgi it doesn't use chunked transfer encoding. I haven't >>> changed the nginx configuration except to swap from an apache backend >>> to uwsgi. The app code hasn't been changed in any way either. >>> >>> Anyway, here's the response header when I use Nginx/Apache/mod_wsgi: >>> >>> Connection close >>> Content-Encoding gzip >>> Content-Length 135 >>> Content-Type text/html; charset=utf-8 >>> Date Wed, 25 Jan 2012 23:15:16 GMT >>> Server nginx >>> Vary Cookie,Accept-Encoding >>> >>> Here's the response header when I use Nginx/uWSGI: >>> >>> Connection close >>> Content-Type text/html; charset=utf-8 >>> Date Wed, 25 Jan 2012 23:18:12 GMT >>> Server nginx >>> Transfer-Encoding chunked >>> Vary Cookie >>> >>> >>> >> >> It looks like you have enabled gzip in apache config, that's why nginx >> manages them differently. By the way can you post nginx config for both >> mod_wsgi and uWSGI and uWSGI config ? >> >> -- >> Roberto De Ioris >> http://unbit.it >> >> >> ------------------------------ >> >> Message: 2 >> Date: Thu, 26 Jan 2012 07:37:19 +0100 (CET) >> From: "Roberto De Ioris" <[email protected]> >> To: [email protected] >> Subject: Re: [uWSGI] emperor mode - logging >> Message-ID: >> <[email protected]> >> Content-Type: text/plain;charset=iso-8859-1 >> >> >> >>> On Jan 25, 2012 9:31 AM, "Damjan" <[email protected]> wrote: >> >>> >>> I just saw/realized this while looking thru code the other day ... >>> >>> Does $(env_var) work? >> >> yes, it was added during 1.0 development to allows easy heroku deployment >> >>> >>> Also looks like @(file) will do something cool, include probably. >> >> yes, i added it for a project of my company but i really do not know what >> new way of config it opens :) >> >>> >>> You could possibly use an env var to fill a placeholder in a common >> config file ... not sure offhand how to include from XML though. >>> >> >> check this thread, it is still a work in progress but should be enough for >> mixing env vars abd placeholders: >> >> http://projects.unbit.it/uwsgi/ticket/12 >> >> -- >> Roberto De Ioris >> http://unbit.it >> >> >> >> -- >> Roberto De Ioris >> http://unbit.it >> >> >> ------------------------------ >> >> Message: 3 >> Date: Thu, 26 Jan 2012 09:11:22 +0100 (CET) >> From: "Roberto De Ioris" <[email protected]> >> To: "uWSGI developers and users list" <[email protected]> >> Subject: Re: [uWSGI] emperor mode - logging >> Message-ID: >> <[email protected]> >> Content-Type: text/plain;charset=iso-8859-1 >> >> >>> Now for more fun. I tried using inherit mode to setup some defaults for >>> my apps. >>> >>> So instead of starting like this: >>> >>> >>> /usr/local/bin/uwsgi --emperor /etc/uwsgi/vassals -d >>> /var/log/uwsgi_emp.log >>> >>> >>> I tried this (with my daemonize line above in the defaults.ini as >>> daemonize = /var/log/uwsgi/%n.log) -- but it threw an error on starting. >>> >>> >>> # /usr/local/bin/uwsgi --inherit /etc/uwsgi/defaults.ini >>> >>> >>> So I landed here instead: >>> /usr/local/bin/uwsgi --inherit /etc/uwsgi/defaults.ini >>> --daemonize=/var/log/uwsgi/uwsgi.log --pidfile=/var/run/uwsgi/uwsgi.pid >>> >>> >>> Sample defaults file is below. The problem, which I verified in the log >>> captured in the app log *above*, is none of these settings >>> >>> made it into the master for the app. harakiri didnt get turned on, idle >>> not set, etc. Am I missing something ? >>> >> >> inherit should be used in vassals config as it is meant to extend the >> current config. >> >> I think you are referring to --vassals-inherit <file> >> >> that will automatically apply <file> to each of the vassals automatically. >> >> You can specify an unlimited number of vassals-inherit options. When >> conditional options will be implmented this will allows unlimited way of >> config. >> >> -- >> Roberto De Ioris >> http://unbit.it >> >> >> ------------------------------ >> >> Message: 4 >> Date: Thu, 26 Jan 2012 11:00:10 +0100 >> From: ?ukasz Mierzwa <[email protected]> >> To: [email protected] >> Subject: [uWSGI] static file response time vs memory usage >> Message-ID: <1381886.Qrv2aTo3pQ@kbox> >> Content-Type: text/plain; charset="utf-8" >> >> Hi, >> >> after adding avg_rt and rss_size fields to carbon graphs I've noticed funny >> thing: avg_rt looks is related to memory usage (or looks like it is), when >> rss_size grows avg_rt also grows, look at the graphs below. >> >> average response time: >> http://imageshack.us/photo/my-images/11/avgrt.png/ >> >> memory usage: >> http://imageshack.us/photo/my-images/831/rsssize.png/ >> >> Maybe: >> a) stats are wrong, response times are constants, only the time needed for >> metrics gathering grows (?) or other issue related to measuring avg_rt >> b) when memory grows uWSGI has more pages to crawl when serving request >> >> App used is just serving static files with --static-index, I use it to test >> my >> whole setup in real life conditions. I've disabled KSM in vassal config and >> it >> had no effect. The avg_rt values are small and so it is likly that this is >> measurment error but the behaviour is very stable and happens always after >> restarting vassal. Version used is 1.0.2.1 with carbon patch from #76. >> I do not report this as an issue that needs resolving, it's only observation. >> >> ?ukasz Mierzwa >> >> >> ------------------------------ >> >> _______________________________________________ >> uWSGI mailing list >> [email protected] >> http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi >> >> >> End of uWSGI Digest, Vol 28, Issue 35 >> ************************************* > > > > -- > Guy Knights > Systems Administrator > Eastside Games > www.eastsidegamestudio.com > [email protected] -- Guy Knights Systems Administrator Eastside Games www.eastsidegamestudio.com [email protected] _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
