Edgewall Software

Opened 14 years ago

Last modified 13 years ago

#9407 closed defect

Severe memory issues/leaks. — at Initial Version

Reported by: josh@… Owned by:
Priority: normal Milestone:
Component: general Version: 0.11-stable
Severity: major Keywords: needinfo
Cc: andcos84@… Branch:
Release Notes:
API Changes:
Internal Changes:

Description

My company has Trac and SVN set up to use locally for our internal development. However, we're having issues whereby Trac's memory usage is slowly building up over a period of around 1-3 days, to the point where it consumes all available RAM, forcing us to restart Apache, or worse, do a hard-reboot of the server.

Running top reveals that it's the httpd (Apache) processes which are eating the RAM. They are also gradually increacing their CPU usage, to the point where the machine is generally idling at around ~10% cpu.

The Swap partition is also not being utilised much, suggesting(?) the actual cause of the slowdown is probably thrashing.

Obviously, this is not ideal, and we'd quite like to identify the cause of the problem and fix it ASAP.

Details of the setup are: Machine OS: Virtualised Fedora 12 64-bit Linux Memory: 1Gb Swap: 2Gb CPU: Intel 2.4GHz Dual-core

Software Apache: 2.2.14 Python: 2.6.2 Trac: 0.11.7 SVN: 1.6.9 mod_wsgi: 3.1

Apache Running 10 instances. (i.e. Whatever that build defaults to, since I didn't configure that.)

Trac ~20 individual projects (all w/own SVN repos). Plugins: AdvancedTicketWorkflow, Developer, MasterTickets, NeverNotifyUpdater, PrivateTickets, TimingAndEstimation, VirtualTicketPermissions, Worklog, WYSIWYG.

With the exception of Trac and it's plugins, all the software is installed from the Fedora repos. Trac and plugins are installed from source.

There's no other signficant software running on that server, so it's fairly certain that Trac is the cause.

We're quite happy to provide more details/feedback if it helps solve this issue.

Change History (0)

Note: See TracTickets for help on using tickets.