Opened 10 years ago

Closed 7 years ago

#11826 closed task (no change required)

Try to reduce memory pressure for Trac instance

Reported by: zooey Owned by: haiku-sysadmin
Priority: normal Milestone:
Component: Sys-Admin Version:
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description (last modified by zooey)

Our Trac instance has a tendency to use a lot of memory when there's load on it.

This is partly due to Apache's mpm_prefork module being in use. We should investigate if it can be replaced by mpm_worker or mpm_event.

Additionally, a considerable part of the memory is used by the Postgresql processes serving the DB-connections. As Postgresql apparently doesn't seem to provide a threaded server model, we should investigate if the number of Postgres processes can be reduced without much impact on the performance.

When high load leads to memory pressure, the VM becomes unresponsive rather quickly, so I guess living with a DB using only few processes is better than leaving things like they are now ...

Change History (5)

comment:1 by zooey, 10 years ago

Description: modified (diff)

comment:2 by jprostko, 10 years ago

I had to face a similar decision with my work's server environment as well in the past, which was using Apache with the prefork MPM and mod_php. Initially I was going to go with using Apache with mpm_event, but ultimately I switched to using Nginx/PHP-FPM since I prefer Nginx's configuration syntax, and well, it just simply performed better and used less memory.

That said, for our case, I think we could easily switch to using the event MPM in Apache and explore using either FastCGI (mod_fcgid) or mod_wsgi in daemon mode. This should suit our needs quite well.

With respect to Postgres, is this only used for Trac on that VM? I'm just wondering if maybe MariaDB would make more sense for this particular use case.

That said, initially we should certainly look into ways to avoid the memory pressure caused by Postgres, as that may resolve the problem without having to consider something more radical like moving to a different database server backend.

comment:3 by zooey, 10 years ago

To clarify: we are already using mod_wsgi for the Trac instance, so my reference to the Apache mpms is probably rather irrelevant - sorry about the confusion.

But the task remains the same: analyzing the memory consumption of our Trac instance and try to find a way to reduce it.

in reply to:  3 comment:4 by jprostko, 10 years ago

Replying to zooey:

To clarify: we are already using mod_wsgi for the Trac instance, so my reference to the Apache mpms is probably rather irrelevant - sorry about the confusion.


Okay, I understand. I don't yet have a good grasp yet of how everything is implemented on the servers, so I'm bound to introduce some confusion to the conversation as well. I'll certainly look around more if/when I have proper access though. I kind of assumed you were using mod_python with the prefork MPM though. You know what they say about assumptions...

But the task remains the same: analyzing the memory consumption of our Trac instance and try to find a way to reduce it.


Indeed. I'll see what others are doing to scale Trac, and what may work best for our individual case.

comment:5 by nielx, 7 years ago

Resolution: no change required
Status: newclosed

This is no longer an issue with the new server configuration, thought probably we will need to talk/think about scaling at some point.

Note: See TracTickets for help on using tickets.