What to use my RAM for?

I would like to know as well. I have a similar setup without the mail server. Should I make changes to the configuration of nginx, mysql or php-fpm to make better use of the upgrade?

Thanx.

I don't see anything wrong about the spam filter. Filling your RAM for no reason is already a waste of resources because that RAM could've been used for caching - you might as well waste it to fight spam instead.

Yeah, but the thing is, I actually get extremely low volumes of spam, there's simply no point in setting up spam fighting stuff…

you should donate to http://www.downloadmoreram.com/

APC or memcached.

Or leave it alone and let the Linux kernel use it for caching your file system.

i like to run a little swap, to get unused pages out of memory and into swap. Then the freed memory can be used for more useful things.

Like I always say, swap out is good, swap in is bad.

What I've done now, is, set up a 128M zram compressed swap device. So unused pages get swapped into memory that is compressed.

I still have a traditional disk swap area, but it's at a lower priority, so will only get used if the higher priority zram swap

is filled, which won't happen due to tuning.

I don't have much experience with it on a vps, but by all reports on chromebooks, it's excellent,

and allows many more concurrent tabs to be running at the same time.

You can also turn it on on your android phone. which I'm about to try.

php_apc as sednet said. Use the apc.php to see how much you're using and tune appropriately.

If you're using innodb tables in your MySQL increasing the innodbbuffersize.

Also consider increasing query cache size may have some benefits.

Leave at least 25% for Linux to use as disk cache, and other things that spike up in RAM.

Should we also be doubling our SWAP?

@pmp6nl:

Should we also be doubling our SWAP?
Nope.

If you use up all your RAM and hit swap, you'll still be having a bad time.

@pmp6nl:

Should we also be doubling our SWAP?

This is an age old discussion that never got resolved.

OS's that use swap space reservation will not allocate ram unless there is corresponding swap space that can be reserved for that ram. This means you will never get a page of ram you can't swap out, it also means you need swap space that is at least equal to your physical memory or you get memory you can't use. Linux doesn't use swap space reservation.

OS's that don't use swap space reservation can end up in the situation where they have to swap out a page of memory and there is nowhere to swap it to. When that happens the system needs to free up memory instantly and at any cost. In Linux this situation is handled by the OOM killer. Linux will literally murder whatever process is nearest to free the needed ram.

Linux swaps wrong and always has but it doesn't have the annoying limit where you can't allocate more physical memory than you have swap space to cover.

The pragmatic answer is to give your system about 512M of swap and do whatever you can to prevent your system using it. Swapping out memory pages that have not been used for hours is fine but if running processes need to access swapped out memory you take a major performance hit.

@sednet - not quite; it sounds like you're confusing "overcommit" with "backing store". In the SunOS 4 days every page of virtual memory needed to be backed by a page of swap; so 128M RAM + 192M swap == 192M virtual memory. If you only had 64M of swap then you only had 64M of VM - less than physical RAM! So you always needed at least as much swap as you had physical memory, just to draw even. Thus the rule of thumb; "twice ram = swap"

Linux and pretty much every modern Unix doesn't do this, so this old rule of thumb isn't true. It's never been true on Linux. 128M RAM + 128M swap == 256M VM.

However, Linux does have a failure mode; overcommit allows you to allocate 300M of memory! It just hopes you don't really want to use all the memory you asked for… when a VM page is requested for actual use (rather than being reserved) that exceeds actual VM capacity then the OOM kicks in.

You can tune Linux overcommit with sysctl values:

vm.overcommit_memory = 0
vm.overcommit_ratio = 50
vm.oom_dump_tasks = 1
vm.oom_kill_allocating_task = 0
vm.panic_on_oom = 0

With overcommit turned off then the program that requests more memory is refused it at allocation time, rather than at use time.

So imagine the following:

char *a;

a=(char )malloc(10241024*1024);

a[400]='a';

With overcommit turned off this program will require 1G of free VM to run in because the program has requested a malloc() of 1G. You'll need 128M RAM + 1G swap (close enough) to run this program. However the programs actual page usage is much much smaller than that; just a handful of pages so the machine won't actually be doing much paging, fortunately. With overcommit turned on, your program will run just fine and no one cares, even though we only have 128M RAM + 128M swap.

Now:

char *a;

int i;

a=(char )malloc(10241024*1024);

for (i=0;i<102410241024) a__='a';

With overcommit turned on (the default) the program will slowly start to use up all 1G of VM. If you use up all your VM then the OOM will kick in and kill your program (or, potentially, another innocent program if that was the one that requested a new page).

You can see there are pro's and con's of the overcommit feature and there have been religious wars about it :-)

With overcommit turned on, programs may run that otherwise wouldn't fit (JVM's may fit into this category with -Xms). But programs may be OOM-kill'd at any place, just because a new VM page is needed.

With overcommit turned off then programs requesting reservation of pages that aren't free will be refused and can (if properly coded) catch this case. How many programs are properly coded? Well, at least those that aren't will SISGSEGV :-)

I won't say overcommit is necessarily bad; I'm not really a fan, though. I leave it turned on and try to scale my machines to never actually need swap :-)__

Yeah especially for Wordpress or php sites, give that memory to apc.

sudo apt-get install php-apc

Edit /etc/php5/apache2/conf.d/apc.ini (Ubuntu location)

Set this crazy high, like:

apc.shm_size=512M

Restart apache, sites should be snappy.

APC is a huge win for WordPress and other big PHP apps. Without it, PHP reads and parses every PHP file on every request, which adds a huge amount delay to request processing time. With it, PHP files are parsed only once and then cached in RAM. I can't remember the exact number, but APC only takes, maybe, 10-20MB to cache parsed versions of all the WordPress PHP files.

Allocating any more RAM to APC yields no real benefit, unless you use a Wordpress caching plugin that makes use of APC. Many of those plugins can also use Memcached as a caching backend, but tend to avoid adding unnecessary complexity to my infrastructure, and I think Memcached isn't a big win until you have multiple servers since it lets cache be shared across machines.

What I'm doing with my RAM bonus:

* Doubling the max number of Apache workers to 24. In my previous testing having 3x as many workers as cores seemed to ensure maximal CPU utilization without wasting memory.

Tweaking mySQL (maybe).

Leaving the rest to linux to use as a disk cache until I think of something better to do with it.</list> 

I may try memcached to see if it makes any measurable difference, but I'm not expecting much.

Regarding swap space. I like having some so that stale memory doesn't waste RAM. At this point, swap is pretty useless because disk I/O latency and transfer rates (for spinning disks, at least) has grown much much more slowly than almost else, particularly system memory sizes. Back in the old days, you might be able to swap the entirety of RAM in, say, a second. These days, you can only swap a tiny fraction of RAM in the same amount of time.

@reaktor:

Yeah especially for Wordpress or php sites, give that memory to apc.

sudo apt-get install php-apc

Edit /etc/php5/apache2/conf.d/apc.ini (Ubuntu location)

Set this crazy high, like:

apc.shm_size=512M

Restart apache, sites should be snappy.
This is ridiculous unless you actually have 512MB of PHP to cache.