All products 
How much RAM and how many cores a website needs
Most websites are fine with 2 GB of memory and one or two cores; a shop with thousands of products needs 4 GB and two cores. Memory matters more than cores: when it runs out, the site slows down or crashes, while an extra core without memory adds almost nothing. Below I show how to work out the memory for your site and how to see what it actually uses.
If the site is not live yet and you do not know what to take, start with 2 GB of memory and one or two cores. That is enough for a blog, a company website and a small WordPress shop, and most hosts let you upgrade the plan later without reinstalling. If the site is already running, there is no need to guess: in five minutes you can see how much memory it uses and pick a plan with about 30% headroom.
The most common mistake goes one way: people take four cores and 1 GB of memory because cores sound more impressive. For a website that is a bad pair. PHP and the database eat a gigabyte within minutes, the server starts swapping memory to disk, and pages take several seconds to open while the processor sits almost idle.
What the money buys
I took about 27,700 VPS plans from 2,200 hosts in the accsly catalog of 27 October 2026, grouped them by monthly price and found the median memory, cores and disk for each tier. The catalog stores prices in roubles, so the dollar tiers are converted and rounded.
| Price per month | Memory | Cores | Disk |
|---|---|---|---|
| under $3 | 1 GB | 1 | 20 GB |
| $3–7 | 2 GB, a quarter have 1 GB | 1 | 25 GB |
| $7–11 | 2 GB | 2 | 40 GB |
| $11–22 | 4 GB | 2 | 60 GB |
| $22–45 | 8 GB | 4 | 100 GB |
| $45–90 | 12 GB | 6 | 160 GB |
The usual ratio on the market is one core per 2 GB of memory. Plans with 2 GB split almost evenly: half have one core, half have two. With 4 GB, 61% of plans have two cores; with 8 GB, 57% have four.
The location of the data centre moves the price as well. A 4 GB server costs about $20 a month at the median across all countries, while in the cheaper markets, such as Turkey or Russia, the same memory is closer to $14–15. Selections by size: 2 GB VPS, 4 GB VPS, 8 GB VPS.
Where the memory goes on a web server
A PHP site with a database shares memory between four consumers. Once you know their appetite, the size you need can be worked out on the back of an envelope.
- The system itself. A fresh Ubuntu or Debian takes 150–300 MB after boot.
- The nginx web server takes tens of megabytes; you can leave it out.
- PHP-FPM. Each PHP worker process takes 40–100 MB, and WordPress with a dozen plugins or Magento can take more. There are as many processes as requests the site handles at the same time.
- MySQL or MariaDB. The biggest consumer. The database keeps its buffer of data and indexes in memory, plus a few megabytes for each connection.
A control panel such as cPanel, Plesk or FastPanel adds another 200–500 MB, and Redis for caching anything from 50 MB up to the size of what you store in it.
Say you have a WooCommerce shop with 5,000 products and an 800 MB database. The system takes 300 MB, the database buffer for all the data with some room 1 GB, the database itself another 300 MB on top, 15 PHP processes at 80 MB each 1.2 GB, and Redis 100 MB. That comes to about 3 GB. On a 4 GB server a gigabyte is left over, which Linux uses as a file cache, and that is a good thing. The shop will also start on 2 GB, but you will have to halve the database buffer and the number of PHP processes, and during a sale the catalog pages will get slower.
And how many cores?
Fewer than you might think. One core runs one PHP request at a time. If a page is built in 200 ms, a core can serve five such pages per second, and two cores ten.
Let us turn that into visitors. A site with 10,000 visitors a day shows about 30,000 pages. The busiest hour takes roughly a tenth of that, 3,000 pages, which is less than one per second. One core copes with that. A second one helps so that the admin area, product imports, backups and search engine crawlers do not slow the site down for visitors. And with a page cache turned on, most requests never reach PHP at all.
Cores are needed where many pages cannot be cached: catalog filters, search, the cart, customer accounts. Heavy background jobs also eat them, for example image processing, product feeds to marketplaces and price list imports. So do several sites on one server.
Paying for cores in advance hurts. With 4 GB of memory, a four-core plan costs about $27 at the market median and a two-core plan about $19, a difference of $8 a month. With 8 GB the difference between two and four cores is only about $3, so at that size four cores are almost free. For PHP the clock speed matters too: a single page is built on a single core, and at 4.5 GHz it will be ready noticeably faster than at 2.2 GHz. Such plans are in the high-frequency CPU VPS selection.
What to take for typical sites
- A landing page, static site or business-card site without a database: 1 GB and one core. These are the cheapest plans, and there is nothing to overpay for: 1 GB VPS.
- A WordPress blog or company website with caching: 2 GB and one or two cores: VPS for WordPress.
- A shop with thousands of products on WooCommerce, OpenCart or PrestaShop: 4 GB and two cores: VPS for an online store.
- Magento or a shop with a large catalog: from 4 GB, and 8 GB with four cores once the catalog runs into tens of thousands of products.
- A Laravel application with queues and Redis: 2–4 GB, because each queue worker keeps its own PHP process in memory. Selection: VPS for Laravel.
- Several sites and a control panel: add up what the sites need and add 0.5–1 GB for the panel.
How much memory the site really uses
Log in to the server over SSH and run:
free -mThe output will look something like this:
total used free shared buff/cache available
Mem: 3915 1720 240 60 1955 1890
Swap: 1023 12 1011Do not be alarmed by the small number in the free column. Linux uses spare memory for the file cache, which is the buff/cache column, and gives it back to programs as soon as they ask. The column to watch is available: here the server has 1.9 GB that programs can take right now. If available drops below 10% of total at peak hours, memory is short.
The second check is whether the server is swapping:
vmstat 1 10The command prints a line of figures ten times, once a second. Look at the si and so columns: how much data the server reads from swap and writes to it per second. Zeros mean all is well, even if something is taken in the Swap line of free. If they constantly show hundreds or thousands, the server is moving memory to disk, and that slows a site down more than any other problem.
The third is whether the system has killed processes for lack of memory. When memory runs out completely, the Linux kernel picks the largest process, often MySQL, and terminates it. Visitors see this as an "Error establishing a database connection" or a 502 error.
journalctl -k | grep -i -E 'out of memory|killed process'If the command finds anything, memory has run out at least once. Take a bigger plan or reduce the appetite of PHP and the database, as shown below.
Who ate the memory: htop and ps
Start htop (on Ubuntu and Debian it installs with apt install htop) and press M to sort processes by memory. The RES column shows how much a process occupies in RAM. At the top you will usually see mysqld or mariadbd and a long tail of php-fpm processes.
You can count how much memory goes to PHP in total and per process with one line:
ps -eo rss,comm | awk '/php-fpm/ {s+=$1; n++} END {printf "%d processes, %.0f MB total, %.0f MB per process\n", n, s/1024, s/n/1024}'The total comes out slightly high, because PHP processes share part of their memory. For an estimate that is good enough. Run the command during the day, when the site has visitors: at night the processes are idle and look smaller.
The average process size tells you how many PHP processes you can allow. Decide how much memory you give to PHP and divide it by the process size. For example, 1,200 MB at 80 MB per process gives 15 processes. This number goes into the pm.max_children setting in the pool file; on Ubuntu and Debian that is /etc/php/8.3/fpm/pool.d/www.conf, where 8.3 is your PHP version. Set it higher, and during a rush of visitors PHP will take all the memory and the system will start killing processes. Set it lower, and extra requests will wait in a queue, but the server will stay up.
The MySQL buffer: the biggest consumer and the biggest lever
The database is fast as long as its data and indexes fit into the buffer in memory. You can find out how much the tables weigh with a query in the mysql console:
SELECT ROUND(SUM(data_length + index_length) / 1024 / 1024) AS mb
FROM information_schema.tables WHERE engine = 'InnoDB';The current buffer size:
SHOW VARIABLES LIKE 'innodb_buffer_pool_size';After installation it is often 128 MB. For a shop with an 800 MB database that is far too little: every catalog filter will read from disk. Two counters show whether the buffer is big enough:
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%';Divide Innodb_buffer_pool_reads by Innodb_buffer_pool_read_requests. The first number is how many times the database had to go to disk, the second how many reads there were in total. If the result is below 0.01, meaning less than 1% of reads go to disk, the buffer is big enough. Look at these figures after the server has been running for at least a day.
Make the buffer equal to the data size plus 10–20% for growth, but on a server where PHP runs alongside, no more than half of all memory. The value is set with the line innodb_buffer_pool_size = 1G in the [mysqld] section of the configuration (on Ubuntu that is /etc/mysql/mysql.conf.d/mysqld.cnf, for MariaDB a file in /etc/mysql/mariadb.conf.d/), after which the database has to be restarted. If the database does not fit even into half the memory, that is an honest reason to take a bigger plan. A fast disk helps in that situation too; see the article NVMe or SSD for a website.
When to add memory and when to add cores
Memory is short if available drops below 10% at peak, vmstat shows non-zero si and so, or the log has killed processes. Adding cores is useless here.
Cores are short if memory is free but the site is slow under load. Check with uptime: the three numbers at the end of the line show the average load over 1, 5 and 15 minutes. Compare them with the number of cores from the nproc command. If the load stays above the number of cores for long periods at peak hours, and in htop the processor is busy with php-fpm processes, you need more cores or a page cache, which is often cheaper.
There are two cases where a bigger plan at the same host will not help. If top shows a high st value in the %Cpu(s) line, 10% or more, your neighbours on the physical server are taking processor time from you. Only another host or a plan with dedicated cores helps. If wa is high, the processor is waiting for the disk, and it is the disk that needs fixing, not the cores.
If you are torn between two sizes, take the smaller one at a host where the plan can be upgraded from the panel in a couple of minutes. Before buying, check in the description whether the plan can be changed without reinstalling. And if you want to try the site on several configurations, hourly billing is handy: a server for an evening costs well under a dollar. The other plan parameters are covered in the article how to choose a VPS.