There are three differences between each memory scaling mode. The first is how quickly your memory scales, which dictates how fast you are invoiced for memory. The second is how much memory is available within your server. For this value, you can see the column "Available" using the "free" command in Linux. A higher percentage of available memory, means your operating system has more room to improve performance. The third difference is how much Additional Memory is given after adjusting for the available memory; this is just extra memory to make sure your server can quickly adapt to an increase in memory usage.

Having more free memory on your server will increase performance. Your server can scale up memory at a rate of roughly 1GB per second per core. Your application could consume memory at 10x that rate. Aside from your application's needs, your operating system will more aggressively cache and buffer data based on the amount of free memory available to it.

The higher performance scaling modes provide your server with relatively more available memory. The "standard performance" mode follows the commonly accepted advice for how much available memory to allocate.

You will be invoiced for more memory at higher modes, because these settings causing the automatic scaling to ensure you have more available memory.

Your server scales up (and is ultimatey invoiced) based on the "Live" usage on the server overview page. The higher performance scaling modes intentionally provide more available memory to your server. If your live usage is below the amount of available memory your server should have based on the scaling mode selected, our automatic scaling will not attempt to lower your memory usage. Keep in mind that "Standard Performance" is considered best practice. When you pick a scaling mode with higher performance than that, the purpose is not to lower your memory costs. You should expect to pay at minimum for the amount listed as "Additional Memory".

Lower Performance

With a relatively recent linux kernel, your server should wait on extra memory from Slicie before invoking OOM Killer. That means that - to some extent, even on the "Lower Performance" plan you should not run into any issues. Still though, you will see an impact on performance. We really don't recommend this option, because we charge so little for memory; it's hard to imagine why this would be cost effective.

Scaling Starts at:
110% of your invoiced memory
Desired Available Memory:
20%
Additional Memory:
None

Standard Performance

This is the default mode. The purpose is to cause your server to give back memory that might be wasted otherwise, while keeping a healthy balance between cost and performance.

Scaling Starts at:
100% of your invoiced memory
Desired Available Memory:
30%
Additional Memory:
None

High Performance

Performance modes starting here will prioritize performance over cost. We recommend this setting for demanding applications.

Scaling Starts at:
75% of your invoiced memory
Desired Available Memory:
50%
Additional Memory:
4 GiB

Extreme Performance

With 80% of your memory available for caching and buffers, and an extra 16 GiB for "icing on the cake", it's smooth sailing for very demanding apps.

Scaling Starts at:
50% of your invoiced memory
Desired Available Memory:
60%
Additional Memory:
8 GiB

Maximum Performance

When you just can't tolerate anything less than the best. You saw extreme and thought, "not good enough."

Scaling Starts at:
25% of your invoiced memory
Desired Available Memory:
70%
Additional Memory:
16 GiB