Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I used to have a VPS (512MB) from Linode and I was running nginx + php5-fpm (which comes with php5.3.3) on Debian Lenny (i686). The total memory usage was about 90-100MB.

Now I have another VPS (different hosting company) and I also run nginx + php5-fpm on Debian Lenny (x86_64). The system is 64-bit, so the memory usage is higher now, about 210-230MB, which I think is too much.

Here is my php5-fpm.conf:

pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 2
pm.max_spare_servers = 5
pm.max_requests = 300

That's what top command tells me:

top - 15:36:58 up 3 days, 16:05,  1 user,  load average: 0.00, 0.00, 0.00
Tasks: 209 total,   1 running, 208 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0%us,  0.0%sy,  0.0%ni, 99.9%id,  0.1%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:    532288k total,   469628k used,    62660k free,    28760k buffers
Swap:  1048568k total,      408k used,  1048160k free,   210060k cached

22806 www-data  20   0  178m  67m  31m S    1 13.1   0:05.02 php5-fpm
 8980 mysql     20   0  241m  55m 7384 S    0 10.6   2:42.42 mysqld
22807 www-data  20   0  162m  43m  22m S    0  8.3   0:04.84 php5-fpm
22808 www-data  20   0  160m  41m  23m S    0  8.0   0:04.68 php5-fpm
25102 www-data  20   0  151m  30m  21m S    0  5.9   0:00.80 php5-fpm
10849 root      20   0 44100 8352 1808 S    0  1.6   0:03.16 munin-node
22805 root      20   0  145m 4712 1472 S    0  0.9   0:00.16 php5-fpm
21859 root      20   0 66168 3248 2540 S    1  0.6   0:00.02 sshd
21863 root      20   0 66028 3188 2548 S    0  0.6   0:00.06 sshd
 3956 www-data  20   0 31756 3052  928 S    0  0.6   0:06.42 nginx
 3954 www-data  20   0 31712 3036  928 S    0  0.6   0:06.74 nginx
 3951 www-data  20   0 31712 3008  928 S    0  0.6   0:06.42 nginx
 3957 www-data  20   0 31688 2992  928 S    0  0.6   0:06.56 nginx
 3950 www-data  20   0 31676 2980  928 S    0  0.6   0:06.72 nginx
 3955 www-data  20   0 31552 2896  928 S    0  0.5   0:06.56 nginx
 3953 www-data  20   0 31552 2888  928 S    0  0.5   0:06.42 nginx
 3952 www-data  20   0 31544 2880  928 S    0  0.5   0:06.60 nginx

So, the question is there any way to use less memory? Btw, I have 16 cores and it would be nice to make use of them...

share|improve this question

With the little RAM you have your VPS will be swapping long before you'll use all the cores - just forget about it: run 1 nginx worker process - with will be able to handle WAY more requests than you need.

Since you are most likely running PHP from Lenny distro you have an awful lot of stuff compiled into it. Recompiling PHP will save you some RAM. So will not loading the extensions you don't need - check in php.ini what is being loaded.

PHP-FPM sends requests from queue to workers (round robin), so you can reduce number child processes to 3-4 if you have to - if there are more requests they will just wait for their turn.

  • Rest of the vps

Check what services you are running and if you really need them. Default installation includes a lot of things

If you have saslauthd running and you want it to be running be sure to add a cron job that will restart it on daily basis - it has had a nasty memory leak for ages now and I've seen it bloat to 1.5GB in about two weeks on one of my boxes.

share|improve this answer

I'm not 100% sure about reducing memory usage for php5-fpm, however, if you would like to use all 16 cores with nginx, change the worker_processes to 16 in the nginx.conf

share|improve this answer

You can lower the amount of php-fpm servers, or reduce the amount of memory that php can use.

"x" is the amount of memory you can allow php/fpm to use, then divide x by the amount of memory each php script might ever need to use (memory_limit) and you have number of php-fpm "servers" (not including any opcode cache or overhead by php-fpm).

For example: If you can let it use a maximum of 256M, and each script is limited to 64M, then '256 / 64 = 4' php-fpm servers.

My guess is that spending a few extra dollars on more memory is worth every penny, though.


share|improve this answer

This is normal that 64 bit system use more memory than 32 bit one, as pretty much every number or pointer in code would need twice more. Do you really need 64 bit?

Strictly CPU bound 64 bit programs can be faster than 32 bit ones on the same computer, but in your situation (very little RAM) the less RAM programs use the better, as more of it could be used for cache.

I'd recommend going back to 32 bit.

share|improve this answer
@sonassi: Why do you think a lot of operating systems / programs have higher memory requirements for 64 bit version than 32 bit? I know that installing 32 bit system on computer with more than 3GB of RAM does not make sense. But with 0,5GB of RAM a difference would be very significant. Just try this - download some kind of Linux LiveCD in 32bit and 64 bit versions and compare their memory usage. 64 bit is not unconditionally better. – Tometzky Jun 29 '12 at 10:20
I'm not going to get into a discussion, but the answers here are pretty thorough regarding 32bit vs 64bit - . Simply put, potential for increase memory usage is not a sufficient reason to regress to 32bit. But yes, you are correct it can incur an increase in memory usage - but the benefits usually far outweigh that (faster registers, operations within memory etc.) – Ben Lessani - Sonassi Jun 29 '12 at 10:29
@sonassi: There's even a new application binary interface in latest Linux kernel (3.4) - x32 ABI - that is created because of this. It allows for running programs in 64bit mode (for more registers etc.) but with 32 bit pointers (for less RAM usage). – Tometzky Jun 29 '12 at 10:30
Understood. I was perhaps a bit hasty to respond to your answer. If you edit your answer above, I can remove the down vote. – Ben Lessani - Sonassi Jun 29 '12 at 10:47

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.