Ticket #5255 (closed defect: duplicate)
Opened 5 years ago
Last modified 17 months ago
Trac resource leak?
| Reported by: | ian@… | Owned by: | jonas |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | general | Version: | 0.10.4 |
| Severity: | normal | Keywords: | mysql memory |
| Cc: | |||
| Release Notes: | |||
| API 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
Change History
comment:1 in reply to: ↑ description Changed 5 years ago by eblot
comment:3 Changed 5 years ago by cboos
- Resolution set to duplicate
- Status changed from new to 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.
comment:4 follow-up: ↓ 5 Changed 5 years ago by ian@…
- Resolution duplicate deleted
- Status changed from closed to 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 in reply to: ↑ 4 Changed 5 years ago by pacopablo@…
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.
comment:6 follow-up: ↓ 7 Changed 5 years ago by cboos
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 in reply to: ↑ 6 Changed 5 years ago by ian@…
comment:9 Changed 4 years ago by ian@…
No, still have the problem.
comment:10 Changed 4 years ago by anonymous
- Keywords mysql added; needinfo removed
comment:11 Changed 4 years ago by cboos
- Milestone set to 2.0
comment:12 Changed 3 years ago by cboos
- Keywords memory added
comment:13 Changed 22 months ago by cboos
- Milestone changed from 2.0 to unscheduled
Milestone 2.0 deleted
comment:14 Changed 17 months ago by cboos
- Milestone triaging deleted
- Resolution set to duplicate
- Status changed from reopened to 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.