Bootstrap Memory Lock Is False
Memory swapping is active while JVM heap is not locked in RAM. When Elasticsearch pages heap to disk, latency and GC behavior 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.
No description available.
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.
Impact: Nodes performance can be heavily penalized if the node is allowed to swap memory to disk. The cluster can be configured to automatically prevent memory swapping on its host machine by setting the bootstrap.memory_lock to true. If bootstrap checks are enabled, the cluster will start only if memory swapping is turned off.