Side effects of setting max-requests on uwsgi config

uwsgi

In order to try and reduce memory usage on our web server, I've had to set the max-requests property on my uwsgi config to 50.

What are the down sides of this?

We've got 10 workers on the site and it looks like workers are being recycled every 20 minutes or so but, so far at least, it seems to be having the desired effect of us not getting near our memory limit.

I'm just slightly concerned that it might side effects for users but I'm not sure. Any ideas?

Best Answer

As far as i know, the only downside of setting max-requests is that when running apps that load on the first request to the server instead of the worker initialization (like Django), every time a worker hits the max-requests limit, the next request that it answers will have a delay. If that delay is short or long, depends on your server specs and the complexity of your app.

Related Solutions

Django, uWSGI and Supervisord config

I found this was pretty confusing until I discovered emperor mode.

This means you can do one supervisord instance to manage all of your configs:

[program:uwsgi]
command=/usr/local/bin/uwsgi --emperor /etc/uwsgi/apps-enabled
stopsignal=QUIT
autostart=true
autorestart=true
redirect_stderr=true

And then you'd pop any config files (ini, xml, yaml) for apps into the /etc/uwsgi/apps-enabled directory.

Not sure if this works with 0.9, but defintely works with 1.0.

Here's an example ini for a Flask app:

[uwsgi]
socket = /tmp/uwsgi_%n.sock
module = wire:app
chdir = /srv/%n/wire
env = WIRE_SETTINGS=/srv/%n/wire/config.py
virtualenv = /srv/%n
uid = wire
gid = www-data
single-interpreter = false
chmod = 770
processes = 3

Reload and evil-reload in uwsgi config

evil-reload-* destroy a worker even if in the middle of a request, while the other one wait for request completion

Best Answer

Related Solutions

Django, uWSGI and Supervisord config

Reload and evil-reload in uwsgi config

Related Topic