Apache/Passenger Tuning on Linode 768

Looks like you have 344 MB of free RAM there… is there anything in specific that happens before/when it runs out of RAM? Do you have anything else installed that's RAM-intensive (e.g. a database server)?

(If you don't know where hoopy got the 344mb figure from, see http://www.linuxatemyram.com/)

> Looks like you have 344 MB of free RAM there… is there anything in specific that happens before/when it runs out of RAM? Do you have anything else installed that's RAM-intensive (e.g. a database server)?

I didn't explain myself well. I am not going out-of-memory anymore since I changed PassengerMaxPoolSize from 6 to 3.

However for 512mb VPS it is common to have PassengerMaxPoolSize=6 but I am on a 768mb VPS, so my application is using much more memory than the others.

ps aux tells me that rails is using 15% of memory for every application instance open, this seems a lot to me, could you comment on this value?

> www-data 406 2.4 15.3 130764 118060 ? Sl 10:12 2:31 Rack: /srv/www/myapplication.it/application

ps:
> If you don't know where hoopy got the 344mb figure from, see http://www.linuxatemyram.com/

you are right, I was looking at the wrong value, thank you

The weird thing about memory allocation is that it's difficult to know how much a process is truly using. If a process forks itself into multiple processes, each gets its own chunk of virtual memory to work with, but some of it inevitably maps to the same physical memory as the parent process. This avoids unnecessary duplication of the common stuff (the program itself, the libraries, etc) while still giving each process its own separate memory space. (This is somewhat like fractional reserve banking; the kernel tries to maintain a particular level of over-commitment, balancing efficiency vs. catastrophe.)

Nevertheless, I usually assume a 1:1 ratio when planning. That is, I assume that each process's virtual memory allocation is fully backed by a real memory allocation of the same size. This is partially conservatism, but it's mostly because it's difficult to assume anything else. The good news is that the system will find other ways to use the excess RAM to better performance.

More to the point, here's the specific suggestions I'd make:

1) Does Apache need to be using mpmprefork in your case? This is usually only necessary when using particularly broken things, like modphp. Consider mpmworker or mpmevent. This will allow more HTTP clients to be served with less RAM.

2) Does PassengerMaxPoolSize need to be larger than it is? Each request will take some amount of time to process, and you'll be able to process n requests simultaneously, excluding anything being handled by Apache itself (e.g. static files).

3) What's your application? You might be able to fit, say, 6 hello-worlds in 512 MB of RAM, but once you throw in some real code and some libraries and a web server and a database server, you no longer have 512 MB of RAM to work with, nor is your application quite as svelte.

It's a balancing act, and probably more of an art than a science. The key thing is to monitor things (munin is your friend) and make sure you don't run out of memory (oom-killer is NOT your friend).

Thank you hoopycat, your reply is really helpful. I will have a look to munin

> 3) What's your application? You might be able to fit, say, 6 hello-worlds in 512 MB of RAM, but once you throw in some real code and some libraries and a web server and a database server, you no longer have 512 MB of RAM to work with, nor is your application quite as svelte.

I am already testing my final application. Essentially is a market place where the users publish ads in the home page (divided by city). The bottleneck is the home page where the users requests all the ads for its city

The bottleneck, you say? About this home page, to-day?

etc, etc… I'd do the usual song and dance about caching (caching! caaaa-ching!) here, 'cept the ensemble has Monday nights off.

@hoopycat:

etc, etc… I'd do the usual song and dance about caching (caching! caaaa-ching!) here, 'cept the ensemble has Monday nights off.

:D :D ahahaha I think I got it! signed in my todo list, thank you!