How to reduce memory consumption of Redmine?

Question

linux

Good afternoon.

Please tell me the possible solutions to the following problem:

There is a virtual server with Ubuntu 10.04 (32 bit) on which Redmine is running. Nobody really touches him, that's why I want him to behave as modestly as possible :)

Everything was done according to this instruction (Apache 2 + Passenger, Redmine 1.0.1) and consumes an average of around 450 MB of memory (according to the selector panel) . What is especially sad is that it periodically crashes and Passenger shows beautiful messages about “Internal server error” (it’s sad because I obviously don’t have enough knowledge for the correct configuration, and there are somehow too many different configuration manuals and it’s easy to get confused in them).

In general, I will be glad if someone tells you in which direction you need to dig at all :)

Google says the solution may have something to do with nginx and Ruby Enterprise Edition. Or I'm wrong?

Answer 1

Even better is nginx+thin.

Answer 2

At a minimum, nginx + passenger will eat several times less.

Answer 3

nginx + unicorn-rails, didn't seem to notice any problems

Answer 4

The problem can be caused by:
1. Version 1.0.1 is quite old (currently 1.3.2 is current).
2. Something in the package for Ubuntu messed up.
3. Something with the passenger.
Possible solution:
1. Build a new Passenger:

$ sudo gem update passenger
$ sudo passenger-install-apache2-module

2. Update ubuntu-redmine (I can make a mistake in the command):

$ sudo apt-get upgrade ubuntu-redmine

3. Demolish the fuck ubuntu-redmine and install the latest version yourself according to this instruction. Only instead of deploying the database, update it according to this instruction (with a preliminary backup of the database and /files, of course).

Answer 5

nginx + unicorn (1 worker) + ruby-1.9.3 (IMHO this is better than ree)

Answer 6

you can simply reduce the number of workers to 2-3.
5.12.1. PassengerMaxPoolSize The maximum number of Ruby on Rails or Rack application instances that may be simultaneously active. A larger number results in higher memory usage, but improved ability to handle concurrent HTTP clients.
Similarly for Unicorn:
worker_processes 2