Hey Graham, Thanks for the reply and the link, it cleared up and confirmed some of the things I've been seeing and thinking.
We've been running mod_python with Apache's mpm_prefork mainly because we run mod_php. The settings for mpm_prefork have been heavily tuned down to keep Apache in line, but each process slowly baloons to eventually take up to 15% of the RAM on our 512mb VPS. As a result we've had to keep the number of processes incredibly low to prevent them eventually eating our system alive. Several solutions have been proposed. Running Trac via mod_fcgid, switching to mpm_worker, and even running Trac as its own daemon and proxying Apache requests through to it... We've also talked about surrendering and outsourcing SVN and Trac hosting. At this point we have to do something, it's just a matter of picking a solution and doing it... I think the link you referenced says it all, but if you've got any more specific recommendations, please let us know. :) On Mon, Mar 30, 2009 at 5:11 AM, Graham Dumpleton < [email protected]> wrote: > > > > On Mar 30, 12:37 pm, Chris Meller <[email protected]> wrote: > > We're running Trac through mod_python, roughly following the instructions > athttp://trac.edgewall.org/wiki/TracInstall > > > > It seems to be a combination of mod_python being a resource hog > > Problems that people have with Apache/mod_python using a lot of > memory, are not because of mod_python, but because of how you have > configured Apache. Specifically, you have chosen the wrong MPM and/or > not changed the default MPM configuration settings to something more > appropriate for a fat Python web application. For an explanation see: > > > http://blog.dscpl.com.au/2009/03/load-spikes-and-excessive-memory-usage.html > > These days mod_python simply isn't the right tool for hosting the ever > increasing size of Python web applications unless you understand > properly how Apache works and how to tune it well. > > Graham > > > and Trac's > > MySQL support still being "experimental". If you take a look at the slow > > query log on the hp.o slice (it's logging non-indexed queries right now > > too), there are a crapload of queries relating to Trac. Looking at them, > > there are a bunch that just seem crazy too. They're either insanely > > brilliant or insanely crazy. I haven't looked into some of the queries > > enough to know which. > > > > For example: > > > > # u...@host: habari_trac[habari_trac] @ localhost [] > > # Query_time: 0 Lock_time: 0 Rows_sent: 0 Rows_examined: 13520 > > use habari_trac; > > SELECT rev FROM node_change WHERE CAST(rev AS signed) > 2828 AND > > > (path='branches/081011-errorhandling/htdocs/system/themes/charcoal/multiple > .php' > > OR path LIKE > > > 'branches//081011-errorhandling//htdocs//system//themes//charcoal//multiple > .php//%' > > ESCAPE '/' OR (path in > > > ('branches','branches/081011-errorhandling','branches/081011-errorhandling/ > htdocs','branches/081011-errorhandling/htdocs/system','branches/081011-erro > rhandling/htdocs/system/themes','branches/081011-errorhandling/htdocs/syste > m/themes/charcoal','branches/081011-errorhandling/htdocs/system/themes/char > coal/multiple.php') > > and change_type='D')) ORDER BY CAST(rev AS signed) LIMIT 1; > > > > On Sun, Mar 29, 2009 at 9:19 PM, Sean Coates <[email protected]> wrote: > > > > > > Trac is always slow... it sucks. I would say any SVN slowness is > > > > probably as a result of this hook hitting Trac. > > > > > Do you have any actual evidence of this, or is this just anecdotal? > > > How are we running python? mod_python? fcgi? cgi? > > > > > S > > > > --~--~---------~--~----~------------~-------~--~----~ 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/habari-dev -~----------~----~----~----~------~----~------~--~---
