Trac – Time for a diet, you’re eating too much memory
After the recent migration of Trac and SVN services at GeekISP, I had hoped that the new version we moved to (0.12.x) would consume a little bit less memory than in the prior 0.11.x deployment. Not so – in fact, memory usage seemed to increase, and rapidly. Sadly Google doesn’t provide a ton of helpful info on this topic, except a lot of people seem to report a similar issue with Trac deployed in a FastCGI setup. I did find one person who invested a bit of energy in a custom solution here, but I had some trouble using his ‘launcher’ binary.
However, the work done by Graham in the above link led me to an even simpler solution. He had already gone through the trouble of making Trac aware of its own memory usage and fought with Python’s threading hilarity to ultimately produce a graceful per-child shutdown. Now all I needed was to manage a small flock of these processes in an easy way, and for that I found multiwatch, which conveniently was available as deb package.
When multiwatch receives the USR1 signal, it will restart all children that it’s monitoring. That’s a little more than I want, since the individual children will be monitoring their own memory usage and when one goes over limit, the others aren’t necessarily there too. It suffices to comment out the kill() call in Graham’s trac.fcgi, and run that directly via spawn-fcgi/multiwatch. Then when an individual child dies multiwatch will restart it, and we have the desired outcome – bounded-memory operation for Trac in FastCGI mode without any dropped requests or manual restarts.