I work with Doug on this issue, and I wanted to provide some additional details about our configuration and what I am seeing.
The server is an Amazon EC2 small instance, running on a dual core Opteron 2.6 ghz w/ 1.66 gig of ram The Trac install lives in the default c:\python25 folder, and the trac / svn data lives on an S3 drive. We have 49 trac environments running here, 4 of which have their own v- host configured, the rest are for internal use and share a root url. All of these environments also have SVN setup. The majority of the shared instances have a common configuration base trac.ini file, with individual files for environment specific configurations. I started out with the 0.11 install of Trac, and have since upgraded to the 0.12dev-r8263 release from SVN (using easy_install and pointing to the SVN repo location), to try and address our performance issues. Under 'About Trac', here is my current config: Trac: 0.12dev-r8263 Python: 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit (Intel)] setuptools: 0.6c9 SQLite: 3.5.2 pysqlite: 2.4.0 Genshi: 0.6dev-r1052 Babel: - mod_python: 3.3.1 Pygments: 1.0 Subversion: 1.5.4 (r33841) jQuery: 1.1.3.1 I have Apache connecting using mod_python, but this slow performance and 100% CPU peak usage persists even if I load a single environment using tracd and shut-down the apache instance. I have gone through the site-packages and, one by one, removed each plugin from the folder and re-started the instance, and I still saw the performance issues (I was trying to isolate the issue to a single plugin, without luck). I applied the patch as suggested in http://trac.edgewall.org/ticket/7785#comment:13 and have seen no improvement. I also have logging currently disabled completely in the hopes of improving performance, still without luck. I did a directory output from my site-packages folder, if it will provide better detail as to plugins I have installed, that you can view here: http://pastebin.com/fea11695 The worst performance seems to be on the wiki pages, but viewing tickets spins the CPU up quite high as well. At one point I attempted to implement the Psyco package (http://psyco.sourceforge.net/) to improve performance, but all plugins have been updated without it again as I saw no performance gains from using it (the package is still in my site-packages, but the code is not in use) At this point I am (sadly) thinking that I may need to re-configure a new server with a clean / new install of python and trac and see how it runs, I really do not know what else to investigate to resolve this problem. Any idea's, as wild as they may be, would be greatly appreciated! Chris Peterson On Jun 4, 6:31 pm, Christian Boos <[email protected]> wrote: > Doug Hughes wrote: > > Hi, > > > We have a new install of Trac running on Windows with Apache. > > (Generally, the same setup as our old Trac instance.) Unfortunately, > > performance is terrible. Requests spike the box to 99% cpu and httpd > > is taking 500mb. We're out of ideas here and I'd like to have someone > > come in, take a look at our config, tell us what we did wrong, and > > then make it work. > > This sounds a lot like ticket #7490. > Please give us more details about your installation > (http://trac.edgewall.org/wiki/NewTicketGuidelines#HowtoProceed). > > You may try 2 different things: > - reduce the log_level if it's set to DEBUG, down to ERROR > - apply the patch on #7785 > (http://trac.edgewall.org/ticket/7785#comment:13) > > -- Christian --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Users" 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-users?hl=en -~----------~----~----~----~------~----~------~--~---
