Just as a point of comparison, this is from dev.laptop.org: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 22732 www-data 15 0 2625m 2.5g 3548 S 0 32.2 317:02.53 trac.fcgi 15142 www-data 15 0 511m 407m 3536 S 0 5.1 46:46.00 trac.fcgi 23190 www-data 15 0 437m 393m 3524 S 0 4.9 42:09.89 trac.fcgi 19822 www-data 15 0 216m 142m 3516 S 0 1.8 13:06.86 trac.fcgi
--Noah Kantrowitz On Jan 1, 2008, at 5:09 AM, Jonas Borgström wrote: > > FYI t.e.o is now running 0.10 again since 0.11 apparently has some > memory usage issues. Last night the server grinded to a halt when a > bunch of trac fcgi processes each allocating more than 600MB resident > memory. > > I've not yet identified which pages require this much memory but I > would > not be surprised if it's some of the more expensive versioncontrol > pages. > > As far as I know memory allocated by the python interpreter is almost > never returned to the operating system so a single memory hungry page > can case this type of problem when using long running processes such > as > fastcgi and tracd. > > As a comparison with Trac 0.10 each trac process on t.e.o never > seems to > allocate more than 100MB. And this server is 64bit so memory usage > should be even lower on 32bit systems. > > Some relevant reading: > http://wingolog.org/archives/2007/11/27/reducing-the-footprint-of- > python-applications > > Cheers, > Jonas > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" 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/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
