{"id":1568,"date":"2026-10-26T22:42:59","date_gmt":"2026-10-26T22:42:59","guid":{"rendered":"https:\/\/affordablevpsserver.com\/blog\/?p=1568"},"modified":"2026-10-26T22:42:59","modified_gmt":"2026-10-26T22:42:59","slug":"elasticsearch-jvm-heap-sizing-single-vps","status":"publish","type":"post","link":"https:\/\/affordablevpsserver.com\/blog\/elasticsearch-jvm-heap-sizing-single-vps\/","title":{"rendered":"Elasticsearch JVM Heap Sizing on a Small VPS: Heap, Page Cache and the Rest of the Budget"},"content":{"rendered":"
\n

Elasticsearch is the classic way to turn a $10\/month VPS into a $30\/month VPS, not because the software is heavy but because of one configuration line: -Xmx<\/code>. The default templates assume a machine with 8–16 GB to spare, and on a 2 GB box the JVM heap, the filesystem page cache, the segment merge buffers and the kernel all compete for the same pages. Get the split wrong and you get either an OOM kill at 3 a.m. or a cluster that sits idle while the disk thrashes. This is a sizing guide for small boxes, with the RAM you actually have to rent as the cost variable — see current small VPS RAM pricing<\/a> before you pick a plan.<\/p>\n

The guidance below applies to Elasticsearch 8.x on a single node with no replicas, which is the realistic shape of a small deployment: a search box for a blog, a log viewer for a handful of servers, or an internal document index.<\/p>\n

Why the 50% heap rule is only half the rule<\/h2>\n

The long-standing advice is “set heap to 50% of RAM, leave the rest to the filesystem”. That guidance comes from production clusters with tens of gigabytes, where 50% still leaves double-digit gigabytes of page cache. On a 2 GB box, 50% heap gives 1 GB to the OS, which has to hold the kernel, the JVM’s own non-heap memory, and every segment file Elasticsearch reads.<\/p>\n

Two mechanisms make that painful. First, Lucene reads segment files through mmap<\/code>; if the page cache is starved, every search becomes a disk read. Second, the JVM reserves memory beyond the heap: metaspace, thread stacks, direct buffers, plus roughly 0.5–1 GB of JVM overhead once heap exceeds 4 GB. Heap is not the process footprint.<\/p>\n\n\n\n\n\n\n\n\n
Heap size<\/th>\nApprox. RSS overhead beyond heap<\/th>\nTypical total process RSS<\/th>\n<\/tr>\n<\/thead>\n
512 MB<\/td>\n250–350 MB<\/td>\n0.8–0.9 GB<\/td>\n<\/tr>\n
1 GB<\/td>\n350–500 MB<\/td>\n1.4–1.6 GB<\/td>\n<\/tr>\n
2 GB<\/td>\n500–700 MB<\/td>\n2.5–2.8 GB<\/td>\n<\/tr>\n
4 GB<\/td>\n700–1000 MB<\/td>\n4.8–5.2 GB<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

That table is why a “2 GB heap on a 4 GB VPS” configuration, copied straight from a tutorial, leaves almost nothing for page cache and gets the node killed under a merge.<\/p>\n

Concrete heap values for 2, 4 and 8 GB boxes<\/h2>\n

These targets assume Elasticsearch plus the OS, with no other heavy service on the box. If you also run Kibana, add 0.5–1 GB or move Kibana to another host.<\/p>\n\n\n\n\n\n\n\n\n\n
VPS RAM<\/th>\nHeap (-Xmx \/ -Xms)<\/th>\nFree for OS + page cache<\/th>\nRealistic index size<\/th>\nVerdict<\/th>\n<\/tr>\n<\/thead>\n
2 GB<\/td>\n512 m<\/td>\n~1.1 GB<\/td>\n1–3 GB of index<\/td>\nWorks for a small log or doc index; no Kibana<\/td>\n<\/tr>\n
2 GB<\/td>\n768 m<\/td>\n~0.8 GB<\/td>\n0.5–1.5 GB<\/td>\nTight; acceptable if index fits cache<\/td>\n<\/tr>\n
4 GB<\/td>\n1 g<\/td>\n~2.5 GB<\/td>\n3–8 GB<\/td>\nThe sweet spot for one node + Kibana<\/td>\n<\/tr>\n
4 GB<\/td>\n2 g<\/td>\n~1.5 GB<\/td>\n2–4 GB<\/td>\nOnly if queries are aggregation-heavy<\/td>\n<\/tr>\n
8 GB<\/td>\n2–3 g<\/td>\n~5 GB<\/td>\n10–25 GB<\/td>\nComfortable single node<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Set -Xms<\/code> equal to -Xmx<\/code>. A growing heap causes pauses, and the reserved-and-touched memory is the same either way; letting the JVM resize just adds GC churn. Never exceed 31 GB even on large boxes — compressed oops and zero-based pointers stop working above that, and pointer compression is lost, which is a different article but the same principle: bigger heap is not automatically faster.<\/p>\n

The settings file that reflects the table<\/h2>\n

On a Debian or Ubuntu package install, the heap lives in \/etc\/elasticsearch\/jvm.options.d\/heap.options<\/code>, not in the main file — editing jvm.options<\/code> directly gets overwritten on upgrade.<\/p>\n

# \/etc\/elasticsearch\/jvm.options.d\/heap.options\n-Xms1g\n-Xmx1g\n<\/code><\/pre>\n
Then set the same node to be single-purpose and honest about its memory:<\/p>\n
# \/etc\/elasticsearch\/elasticsearch.yml\nnode.name: node-1\ndiscovery.type: single-node\nbootstrap.memory_lock: true\nindices.memory.index_buffer_size: 10%\nindices.queries.cache.size: 5%\n<\/code><\/pre>\n
bootstrap.memory_lock<\/code> stops the kernel swapping the heap, which is the right trade on a box with adequate RAM and the wrong one on a box where something else is competing. Locking memory on a 2 GB VPS with 768 m of heap plus Kibana will trigger the OOM killer rather than swap, and an OOM kill takes the whole node down. On 2 GB, leave memory locking off and budget swap instead.<\/p>\n
Swap and OOM behaviour on a small box<\/h2>\n
Swap does not save Elasticsearch performance, but it does prevent the kernel from killing the process during a transient merge spike. A 1–2 GB swapfile with vm.swappiness=1<\/code> is a cheap insurance policy; the goal is that swap is almost never used, not that the node runs from it.<\/p>\n
fallocate -l 2G \/swapfile && chmod 600 \/swapfile\nmkswap \/swapfile && swapon \/swapfile\necho 'vm.swappiness=1' >> \/etc\/sysctl.conf\nsysctl -p\n<\/code><\/pre>\n
Understand the failure modes. If the kernel OOM killer fires, it picks by oom_score<\/code>, and the JVM with the largest RSS usually loses — you get a dead node and a 30-second gap in your dashboard. If Elasticsearch’s own circuit breaker trips instead, you get a CircuitBreakingException<\/code> in the logs and a 429 to the client, which is far more graceful. Configure the breaker limits rather than letting the kernel decide.<\/p>\n
Measuring fielddata and segment memory before you add RAM<\/h2>\n
Most “we need more RAM” conclusions are actually fielddata bloat from a keyword field being sorted or aggregated. Check the node stats and the hot indices before upgrading the plan.<\/p>\n
curl -s localhost:9200\/_nodes\/stats\/jvm,indices\/segments?pretty \\\n  | jq '.nodes[].jvm.mem, .nodes[].indices.segments.memory'\ncurl -s 'localhost:9200\/_cat\/fielddata?v&bytes=g'\ncurl -s 'localhost:9200\/_cat\/segments?v&bytes=g' | sort -k3 -h | tail -20<\/code><\/pre>\n
If fielddata<\/code> is over 10–15% of your heap, the fix is mapping, not money: make the field doc_values<\/code>-based (the default for keyword<\/code>), stop sorting on text<\/code> fields, and avoid high-cardinality terms<\/code> aggregations on analysed strings. Segment memory tells you how much of the index is mmap’d and therefore how much page cache you want to keep free — if segment memory approaches the RAM you have outside the heap, your search latency is disk-bound and a heap increase will not help.<\/p>\n
Reducing merge pressure before renting more RAM<\/h2>\n
Segment merges are the hidden RAM consumer on a small node. Each merge buffers segments in memory and rewrites them, so a bulk reindex can double the working set for a few minutes. On a 2 GB box that is precisely when the OOM killer arrives. Three settings reduce the peak:<\/p>\n