Trac resource leak?

[ian@…]

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.

[eblot]

Replying to ian@dal-acm.ca:

Trac 0.14.2 is installed from source.

Did you mean 0.10.2 ? In any case, please fill in the version field of this ticket. Thanks.

[ian@…]

Oof, that was dumb.

No, I meant 0.10.4

[cboos]

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.

[ian@…]

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.

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

[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)?

[ian@…]

Replying to 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)?

It's currently 1.2.1-p2-4 (Debian package)

I will try to upgrade.

[sid]

Did upgrading our bindings help?

[ian@…]

No, still have the problem.