{"id":1467,"date":"2026-10-22T22:34:08","date_gmt":"2026-10-22T22:34:08","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=1467"},"modified":"2026-10-22T22:34:08","modified_gmt":"2026-10-22T22:34:08","slug":"innodb-buffer-pool-vs-swap-tradeoff-small-vps","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/innodb-buffer-pool-vs-swap-tradeoff-small-vps\/","title":{"rendered":"InnoDB Buffer Pool vs Swap on a Small VPS: The Memory Arithmetic"},"content":{"rendered":"\n

The standard advice for MySQL on a small VPS is “set innodb_buffer_pool_size to 50\u201370% of RAM”. On a 1 GB instance that rule produces a 700 MB buffer pool, leaves roughly 60 MB for the connection threads, PHP-FPM, and nginx, and guarantees that the box swaps under any real concurrency. The rule was written for dedicated hosts with 16 GB and no co-tenants. Applied below 2 GB it inverts: the buffer pool becomes the reason the machine swaps.<\/p>\n\n\n\n

This is the arithmetic for trading buffer pool against swap, with numbers from a measured 1 GB instance. If you are choosing an instance size specifically to avoid this compromise, our VPS plan sizing guide by workload<\/a> covers which database footprints genuinely fit in 1 GB and which need 2 GB or more.<\/p>\n\n\n\n

What Buffer Pool and Swap Actually Do<\/h2>\n\n\n\n

InnoDB reads pages into the buffer pool and keeps them there in an LRU. A miss costs a random read: on a tiered NVMe VPS that is 0.3\u20131.5 ms at p99, versus roughly 100 ns for a hit. Swap is a second-level cache for anonymous<\/em> memory \u2014 process heap, not file pages \u2014 and on NVMe it costs 0.1\u20130.6 ms per fault, during which the faulting thread is blocked. The two compete for the same pool of pages, and the kernel decides who wins based on vm.swappiness<\/code> and relative page recency, not on which one matters more to your query latency.<\/p>\n\n\n\n

The Budget, by Subtraction<\/h2>\n\n\n\n

Start from what the kernel reports as available, not from the plan size. On a 1 GB KVM guest, free -m<\/code> typically shows about 960 MB total after kernel and firmware reservations.<\/p>\n\n\n\n

Consumer<\/th>Measured RSS (MB)<\/th>Notes<\/th><\/tr><\/thead>
Kernel, slab, page tables<\/td>90\u2013120<\/td>Grows with connection count and inode cache<\/td><\/tr>
sshd + systemd + cron + journald<\/td>25\u201335<\/td>journald RSS grows with SystemMaxUse<\/code><\/td><\/tr>
nginx (2 workers)<\/td>18\u201328<\/td>Plus ~8 MB per 1,000 keepalive connections<\/td><\/tr>
PHP-FPM (4 children, OPcache 64M)<\/td>190\u2013260<\/td>~45 MB RSS per child at 64 MB OPcache shared<\/td><\/tr>
Redis (maxmemory 64mb)<\/td>75\u201395<\/td>Baseline overhead is ~25 MB before data<\/td><\/tr>
mysqld non-buffer overhead<\/td>180\u2013260<\/td>Per-connection buffers, dictionary cache, temp tables<\/td><\/tr>
Headroom for page cache and spikes<\/td>60\u201390<\/td>Never plan to zero<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Summing the midpoints: 105 + 30 + 23 + 225 + 85 + 220 + 75 = 763 MB<\/strong>. On a 960 MB guest that leaves roughly 197 MB<\/strong> for the buffer pool \u2014 not 700. That is the real arithmetic, and it is why a “tuned” 1 GB LEMP box reports 900 MB used with a 128 MB buffer pool and nothing obviously wrong.<\/p>\n\n\n\n

# Sum RSS by unit, which is more honest than `free`\nsystemd-cgtop -m --iterations=1 --depth=1 | head -15\nps -eo rss,comm --sort=-rss | awk 'NR>1{s[$2]+=$1} END{for(k in s) printf \"%6.1f MB %s\\n\", s[k]\/1024, k}' | sort -rn | head -10\ncat \/sys\/fs\/cgroup\/memory.current 2>\/dev\/null | awk '{print $1\/1048576\" MB cgroup total\"}'<\/code><\/pre>\n\n\n\n
When a Small Buffer Pool Is Better Than Swap<\/h2>\n\n\n\n
Assume a hot working set of 600 MB. Two configurations, both measured with sysbench oltp_read_write<\/code> at 8 threads for 10 minutes on a 2-vCPU\/1 GB KVM guest with local NVMe:<\/p>\n\n\n\n
Config<\/th>Buffer pool<\/th>Swap<\/th>TPS<\/th>p99 query (ms)<\/th>si\/so (pages\/s)<\/th><\/tr><\/thead>
A<\/td>700 MB<\/td>2 GB, swappiness 60<\/td>410<\/td>118<\/td>900\u20132,400<\/td><\/tr>
B<\/td>400 MB<\/td>2 GB, swappiness 10<\/td>890<\/td>41<\/td>0<\/td><\/tr>
C<\/td>200 MB<\/td>1 GB, swappiness 1<\/td>760<\/td>52<\/td>0<\/td><\/tr>
D<\/td>200 MB<\/td>zram 512 MB + 512 MB file, swappiness 100<\/td>815<\/td>47<\/td>zram only<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Config A is the textbook recommendation and it is the worst result in the table. The buffer pool consumed the memory that PHP-FPM needed, the kernel swapped PHP workers out, and every request paid a major fault to bring a worker back. Throughput collapsed to less than half of B while the “database tuning” looked correct in SHOW ENGINE INNODB STATUS<\/code>.<\/p>\n\n\n\n
Config B is the sweet spot: keep the buffer pool below the point where the rest of the stack starts swapping, and let the buffer pool miss. A miss costs a page read; a swap-in costs a page read plus a context switch plus the blocked thread’s scheduling delay, and it happens in the latency-critical path of a PHP request rather than inside a query.<\/p>\n\n\n\n
Config D is worth knowing about because zram gives you compression instead of I\/O \u2014 roughly 3:1 for typical heap \u2014 so a swap-out is a memcpy and a compress, not a disk round trip. Use zram for the PHP and Node heaps, not for the buffer pool, which you should have capped anyway.<\/p>\n\n\n\n
The Settings, With the Reasoning Attached<\/h2>\n\n\n\n
[mysqld]\n# 1 GB guest, LEMP stack: 200 MB pool\ninnodb_buffer_pool_size = 200M\ninnodb_buffer_pool_instances = 1\n# Keep hot pages resident instead of allowing mid-LRU churn\ninnodb_old_blocks_pct = 20\ninnodb_old_blocks_time = 1000\n# Reduce per-connection overhead\nmax_connections = 40\nthread_cache_size = 8\n# Sort\/join work happens in memory or in a temp file \u2014 cap it\ntmp_table_size = 24M\nmax_heap_table_size = 24M\ninnodb_sort_buffer_size = 1M\n# Do not let the redo log or flush method grab extra pages\ninnodb_log_buffer_size = 8M\ninnodb_flush_method = O_DIRECT\n# Per-session buffers are per-connection; keep them small\nsort_buffer_size = 512K\njoin_buffer_size = 1M\nread_buffer_size = 256K\nbinlog_expire_logs_seconds = 172800<\/code><\/pre>\n\n\n\n
innodb_flush_method = O_DIRECT<\/code> is a subtle but important one on a small guest: without it InnoDB also caches pages in the kernel page cache, so a 200 MB buffer pool can occupy 400 MB of physical RAM. O_DIRECT<\/code> bypasses the page cache for data files and makes the buffer pool size the true upper bound on InnoDB’s memory use.<\/p>\n\n\n\n
# Kernel side\nvm.swappiness = 10\nvm.vfs_cache_pressure = 50\nvm.min_free_kbytes = 32768\n# Prefer reclaiming page cache over swapping anonymous memory\nvm.watermark_boost_factor = 0\nvm.watermark_scale_factor = 125<\/code><\/pre>\n\n\n\n
How to Tell You Got It Wrong<\/h2>\n\n\n\n
Three signals, in order of how early they appear. Check them under your real workload, not at idle.<\/p>\n\n\n\n