Yep, my install scripts compile mod_wsgi, and sometimes even python, etc. (I've also patched mod-wsgi in the past as well with some enhancements before Graham officially released them.)
Thanks! On Wed, Mar 16, 2016 at 7:47 PM, Bill Freeman <[email protected]> wrote: > An extra note: It's not hard to build Apache and mod_wsgi, and even > python itself, from source. I tend to do all three (particularly on Debian > derived distributions, where sys.path has surprises). (I've been known to > build my own PostGress, but usually I'm happy with packages from the > postgres web site. > > It means that you can take updates when you decide it's time, rather than > when the distro gets around to it. Deployment of security fixes is under > your control. On the other hand, you have to do it. Usually you would > have to run your distro's update tool anyway, but that's easier than a new > compile. You have to decide which one is a plus for you. > > You also get to think about configuration, rather than having the easy > path of accepting distro defaults. You can look at that as a plus or a > minus. > > On Wed, Mar 16, 2016 at 7:27 PM, Graham Dumpleton < > [email protected]> wrote: > >> On the question of whether nginx will solve this problem, I can’t see how. >> >> When one talks about nginx and Python web applications, it is only as a >> proxy for HTTP requests to some backend WSGI server. The Python web >> application doesn’t run in nginx itself. So memory issues and how to deal >> with them are the provence of the WSGI server used, whatever that is and >> not nginx. >> >> Anyway, answer the questions below and can start with that. >> >> You really want to be using recent mod_wsgi version and not Apache 2.2. >> >> Apache 2.2 design has various issues and bad configuration defaults which >> means it can gobble up more memory than you want. Recent mod_wsgi versions >> have workarounds for Apache 2.2 issues and are much better at eliminating >> those Apache 2.2 issues. Recent mod_wsgi versions also have fixes for >> memory usage problems in some corner cases. As far as what I mean by >> recent, I recommend 4.4.12 or later. The most recent version is 4.4.21. If >> you are stuck with 3.4 or 3.5 from your Linux distro that is not good and >> that may increase problems. >> >> So long as got recent mod_wsgi version then can look at using vertical >> partitioning to farm out memory hungry request handlers to their own daemon >> process group and better configure those to handle that and recycle >> processes based on activity or, memory usage. A blog post related to that >> is: >> >> * >> http://blog.dscpl.com.au/2014/02/vertically-partitioning-python-web.html >> >> Graham >> >> On 17 Mar 2016, at 7:15 AM, Graham Dumpleton <[email protected]> >> wrote: >> >> What version of mod_wsgi and Apache are you using? >> >> Are you stuck with old versions of both? >> >> For memory tracking there are API calls mod_wsgi provides in recent >> versions for getting memory usage which can be used as part of scheme to >> trigger a process restart. You can’t use sys.exit(), but can use signals to >> trigger a clean shutdown of a process. Again better to have recent mod_wsgi >> versions as can then also set up some graceful timeout options for signal >> induced restart. >> >> Also, what is your mod_wsgi configuration so can make sure doing all the >> typical things one would do to limit memory usage, or quarantine particular >> handlers which are memory hungry? >> >> Graham >> >> On 17 Mar 2016, at 4:29 AM, Kent Bower <[email protected]> wrote: >> >> Interesting idea.. yes, we are using multiple threads and also other >> stack frameworks, so that's not straightforward, but worth thinking >> about... not sure how to approach that with the other threads. Thank you >> Bill. >> >> On Wed, Mar 16, 2016 at 1:11 PM, Bill Freeman <[email protected]> wrote: >> >>> I don't know about nginx, but one possibility, if the large memory >>> requests are infrequent, is to detect when you have completed one and >>> trigger the exit/reload of the daemon process (calling sys.exit() is not >>> the way, since there could be other threads in the middle of something, >>> unless you run one thread per process). >>> >>> On Wed, Mar 16, 2016 at 7:50 AM, Kent <[email protected]> wrote: >>> >>>> I'm looking for a very brief high-level pros vs. cons of wsgi under *apache >>>> *vs. under *nginx *and then to be pointed to more details I can study >>>> myself (or at least the latter). >>>> >>>> Our application occasionally allows requests that consume a large >>>> amount of RAM (no obvious way around that, they are valid requests) and >>>> occasionally this causes problems since we can't reclaim the RAM readily >>>> from apache. (We already have tweaked with and do use >>>> "inactivity-timeout". This helps, but still now and then we hit problems >>>> where we run into swapping to disk.) >>>> >>>> I'm wondering if nginx may solve this problem. I've read much of what >>>> you (Graham) have had to say about the memory strategies with apache and >>>> mod_wsgi, but wonder what your opinion of nginx is and where you've already >>>> discussed this. I've read articles I could find you've written on nginx, >>>> such as "Blocking requests and nginx version of mod_wsgi," but wonder if >>>> the same weaknesses are still applicable today, 7 years later? >>>> >>>> >>>> Thank you very much in advance! >>>> Kent >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "modwsgi" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To post to this group, send email to [email protected]. >>>> Visit this group at https://groups.google.com/group/modwsgi. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >>> -- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "modwsgi" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/modwsgi/wyo2bJP0Cfc/unsubscribe. >>> To unsubscribe from this group and all its topics, send an email to >>> [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at https://groups.google.com/group/modwsgi. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "modwsgi" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at https://groups.google.com/group/modwsgi. >> For more options, visit https://groups.google.com/d/optout. >> >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "modwsgi" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at https://groups.google.com/group/modwsgi. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to a topic in the > Google Groups "modwsgi" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/modwsgi/wyo2bJP0Cfc/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/modwsgi. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/d/optout.
