Opened 17 years ago
Closed 14 years ago
#5255 closed defect (duplicate)
Trac resource leak?
| Reported by: | Owned by: | Jonas Borgström | |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | general | Version: | 0.10.4 |
| Severity: | normal | Keywords: | mysql memory |
| Cc: | Branch: | ||
| Release Notes: | |||
| API Changes: | |||
| Internal Changes: | |||
Description
I've got a tracd setup that hosts 14 projects on a MySQL backend. Memory usage steadily climbs; I usually kill it off around 850mb. The sqlite backend has the same problem. Someone on #trac suggested I try disabling connection pooling in the MySQL backend which used up all the MySQL connections (dozens of connections per project, all sitting there idle.) The server is very low-use, the most significant traffic comes from search engines crawling it.
System is a Sun V20z running Debian 4.0 AMD64. MySQL 5.0 is installed from the Debian package, Trac 0.14.2 is installed from source.
Attachments (0)
Change History (14)
comment:1 by , 17 years ago
comment:3 by , 17 years ago
| Resolution: | → duplicate |
|---|---|
| Status: | new → closed |
Seems a duplicate of #4347, the problem is not specific to a database. The out-of-memory condition is probably directly linked to the excessive amount of connections created.
If you use apache, try using less processes, e.g. by using the mpm_worker thread model.
follow-up: 5 comment:4 by , 17 years ago
| Resolution: | duplicate |
|---|---|
| Status: | closed → reopened |
I'm certainly no expert with the trac codebase, but I don't think this is a duplicate of 4347. The excessive connections only occur when connection pooling is disabled in the backend. When I tried that, there was no particularly high memory usage (only around 60mb) because the trac instance couldn't connect to the DB to do anything. Just a glut of idle connections. That specific trait may well be a duplicate of 4347.
… but with pooling enabled, it behaves normally (no excessive connections), it just leaks memory like a sieve, which the other bug doesn't mention.
I'm using Apache but it's only handing things off to tracd.
comment:5 by , 17 years ago
Replying to ian@dal-acm.ca:
I'm certainly no expert with the trac codebase, but I don't think this is a duplicate of 4347.
Yeah, this sounds like the exact opposite of #4347. It appears that there is a db connection leak, even when pooling is turned off.
I would expect his connections to top out at around 14 to 20, not balloon to 100. I had the connection leak on PostgreSQL and solved it by turning off connection pooling, but this seems to exasperated by turing off connection pooling.
follow-up: 7 comment:6 by , 17 years ago
Ok, seems a MySQL specific thing then. What version of the MySqlDb bindings are you using? If not already the latest, can you upgrade to the latest (1.2.2)?
comment:7 by , 17 years ago
comment:10 by , 17 years ago
| Keywords: | mysql added; needinfo removed |
|---|
comment:11 by , 16 years ago
| Milestone: | → 2.0 |
|---|
comment:12 by , 15 years ago
| Keywords: | memory added |
|---|
comment:14 by , 14 years ago
| Milestone: | triaging |
|---|---|
| Resolution: | → duplicate |
| Status: | reopened → closed |
Replying to ian@dal-acm.ca:
Did you mean 0.10.2 ? In any case, please fill in the version field of this ticket. Thanks.