Edgewall Software

Opened 14 years ago

Last modified 13 years ago

#9407 closed defect

Severe memory issues/leaks. — at Version 1

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 (last modified by Remy Blank)

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.)

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 (1)

comment:1 by Remy Blank, 14 years ago

Description: modified (diff)

Can you try to strace the apache processes idling at 10%? That may give an indication about what't they are doing.

As a workaround, you could run mod_wsgi in daemon mode, and limit the number of requests before restarting the process (see the maximum-requests argument to WSGIDaemonProcess).

Note: See TracTickets for help on using tickets.