On 05/06/2012 07:31 AM, Roberto De Ioris wrote:
But why moving away from uWSGI if it already give you all of the features you need to bypass your problem without installing other softwares ? (remember, uWSGI is not about speed as lot of people still think, it is about features) As options: --memory-report (report memory usage in logs after each request) --reload-on-rss<n> (automatically reload when a process consume more than <n> megs of rss memory) --evil-reload-on-rss (same as --reload-on-rss but asynchronously called by the master [dangerous]) --never-swap (force the uWSGI stack to not use swap memory, triggering OOM in case of memory problems)
This. Is. Awesome. That's why I love uwsgi. I did look through the docs but I guess I totally missed these settings.
So I am assuming --reload-on-* would recycle a worker when idle? After a request that triggered that much resource consumption? Am I assuming correctly that evil-reload would not wait for the worker to finish the request? The docs are not clear on this.
> From the app itself: uwsg.mem() -> returns memory usage of the current process uwsgi.reload() -> trigger a graceful reload uwsgi.workers() -> returns a dictionary with workers data (included memory usage)
Excellent!
This is generally not a good programming behaviour (if you do it during a request), but for your specific case it could be a good hack. Remember to add --close-on-exec option to uWSGI avoiding your subprocesses to inherit uWSGI sockets.
Good advice, thanks. .oO V Oo. -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
