Error Log: This is another critical bootstrap check error that prevents your OpenSearch node from starting. You will find it in your opensearch.log.
None
[ERROR][o.o.b.BootstrapChecks] [your-node-name]
max virtual memory areas vm.max_map_count [65530] is too low,
increase to at least [262144]Why… is this happening? This is a safety check. OpenSearch and Lucene use mmap (memory-mapped files) extensively to access shard data on disk. This is a highly efficient I/O method that maps file data directly into the process’s virtual memory space.
Each index segment (and other components) requires its own memory map. The operating system has a limit on how many memory map areas a single process can have, defined by vm.max_map_count.
The default value (e.g., 65530) is far too low for a process like OpenSearch, which can easily need to open hundreds of thousands of files across many shards. If this limit is hit, OpenSearch will crash. This bootstrap check prevents the node from even starting, saving you from a future failure.
Best practice: This is a mandatory fix for any production cluster. You must increase this limit on the host operating system.
1. Temporary fix (to test):
Bash
None
sudo sysctl -w vm.max_map_count=2621442. This will apply the setting immediately but it will be lost on reboot.
3. Permanent fix (recommended):
- Edit the file
/etc/sysctl.conf(or create a new file like/etc/sysctl.d/99-opensearch.conf). - Add the following line:
Ini, TOML
None vm.max_map_count=262144- Save the file.
- Run
sudo sysctl -p(orsudo sysctl --system) to apply the new settings from the file without rebooting.
After applying the fix, you can restart your OpenSearch node.
What else can I do? This is one of several critical sysctl settings (along with nofile limits) required for a stable cluster. If you’re unsure about OS-level tuning, the OpenSearch documentation has a dedicated “Bootstrap Checks” page. You can also ask the community or contact us in The OpenSearch Slack Channel in #General.
