> > > I was hoping there's a way to safely kill a wsgi process from within it, > I could do that only when such largish XML files are requested, or > something else not obvious to me. Doesn't have to be uwsgi, though.
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) >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) > Another way would be to remove XML generation from the wsgi application > altogether into a separate callable and do some subprocess.Popen magick > with minimum rewrite required. Is that even wise/advisable under > (u)wsgi? Spawning external processes? > 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. -- Roberto De Ioris http://unbit.it -- 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.
