{"id":1307,"date":"2026-10-05T22:02:45","date_gmt":"2026-10-05T22:02:45","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=1307"},"modified":"2026-10-05T22:02:45","modified_gmt":"2026-10-05T22:02:45","slug":"diagnosing-vm-max-map-count-mmap-exhaustion-vps","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/diagnosing-vm-max-map-count-mmap-exhaustion-vps\/","title":{"rendered":"Diagnosing vm.max_map_count and mmap Exhaustion on a Small VPS"},"content":{"rendered":"\n

There is a class of VPS failure that produces no CPU spike, no disk pressure and no obvious OOM message: a process simply cannot create another memory mapping and dies with ENOMEM<\/code> or Cannot allocate memory<\/code> while free<\/code> shows gigabytes available. The culprit is usually vm.max_map_count<\/code>, the kernel limit on how many distinct memory-mapped regions a single process may hold. Elasticsearch, Redis with many keys, JVMs and modern databases all hit it on small hosts.<\/p>\n\n\n\n

What the limit actually counts<\/h2>\n\n\n\n

Every mmap()<\/code> call creates a virtual memory area (VMA). The kernel tracks them in a per-process red-black tree, and vm.max_map_count<\/code> caps the total. Allocating heap is not the same as mapping: a process can have plenty of free RAM and still exhaust its VMA budget. Read the current limit and see how close a running process is to it:<\/p>\n\n\n\n

cat \/proc\/sys\/vm\/max_map_count\n\n# current VMA count for a given process\nwc -l < \/proc\/$(pidof elasticsearch)\/maps\n<\/code><\/pre>\n\n\n\n
If the maps<\/code> line count is within a few percent of max_map_count<\/code>, you are on the edge. The next allocation fails, and because the failure arrives as a generic ENOMEM<\/code>, it is routinely misattributed to RAM exhaustion.<\/p>\n\n\n\n
Recognising the symptom in logs<\/h2>\n\n\n\n
The error strings differ by runtime, but they cluster around mapping failures rather than allocation sizes. Grep for them before you start tuning memory:<\/p>\n\n\n\n
journalctl -u elasticsearch --since \"1 hour ago\" | grep -iE 'max_map_count|mmap|Cannot allocate memory'\n\n# JVM instances often surface it as a native memory tracking failure\ngrep -r 'OutOfMemoryError: Map failed' \/var\/log\/*.log\n<\/code><\/pre>\n\n\n\n
A dead giveaway is that free -m<\/code> shows available memory and swap in good shape while the process still refused to start. That combination points at a limit, not a shortage.<\/p>\n\n\n\n
Raising the limit safely<\/h2>\n\n\n\n
The commonly recommended value for Elasticsearch — 262144 — is a reasonable ceiling for a small VPS too. The cost is a slightly larger per-process kernel bookkeeping footprint, which is negligible for the handful of processes a small host runs. Apply it persistently so it survives a reboot:<\/p>\n\n\n\n
# apply now (non-persistent, good for testing)\nsysctl -w vm.max_map_count=262144\n\n# persist across reboots\necho 'vm.max_map_count=262144' > \/etc\/sysctl.d\/99-max-map-count.conf\nsysctl --system\n<\/code><\/pre>\n\n\n\n
Do not crank it to millions “just in case”. A process that maps unboundedly is usually leaking mappings, and hiding that behind a huge limit delays the day you find out.<\/p>\n\n\n\n
Distinguish mmap exhaustion from real memory pressure<\/h2>\n\n\n\n
Before raising any limit, confirm which failure you actually have. The two look similar in logs but need opposite fixes:<\/p>\n\n\n\n