Memory lock disabled
Memory locking is off while the host can still swap. If the JVM heap is paged to disk, latency and garbage collection degrade sharply and can look like node failure.
For a complete list of insights, refer to AutoOps insights.
| Field | Value |
|---|---|
| Component | Elasticsearch |
| Severity | Medium |
| Scope | Node |
| Domains | performance, memory, stability |
The following is an example of what you might see when this insight is triggered. Real insights use live data and links from your deployment or cluster.
bootstrap.memory_lock is false while memory swapping remains available on the host. The JVM heap is not locked in RAM.
AutoOps shows different recommendations depending on how their conditions match your deployment or cluster.
Enable memory lock on nodes
Condition: Always shown for this insight.
As a last resort if OS-level memory locking is not enough, set bootstrap.memory_lock: true in elasticsearch.yml on each affected node, then perform a rolling restart. This keeps the JVM heap from being swapped out.
Enable OS memory lock
Condition: Always shown for this insight.
Turn off memory swap so Elasticsearch can lock heap in RAM. On Linux, comment out swap entries in /and so on/fstab, or set vm.swappiness to 1. On Windows, turn off the paging file under System Properties → Advanced → Performance → Advanced → Virtual memory.
Elasticsearch performance depends on keeping the JVM heap in physical memory. If the operating system swaps heap pages to disk, search and indexing latency spike and garbage collection can stall the node.
Setting bootstrap.memory_lock to true asks Elasticsearch to lock its address space in RAM. Host configuration must also allow that lock (for example ulimit / memlock settings). When bootstrap checks are enforced, nodes might refuse to start if swap is still enabled.
Until memory lock is enabled and swap is controlled, the node remains exposed to swap-related latency and instability under memory pressure.