|
@@ -34,7 +34,7 @@ If a JVM is started with unequal initial and max heap size, it can be
|
|
|
prone to pauses as the JVM heap is resized during system usage. To avoid
|
|
|
these resize pauses, it's best to start the JVM with the initial heap
|
|
|
size equal to the maximum heap size. Additionally, if
|
|
|
-<<bootstrap.mlockall,`bootstrap.mlockall`>> is enabled, the JVM will
|
|
|
+<<bootstrap.memory_lock,`bootstrap.memory_lock`>> is enabled, the JVM will
|
|
|
lock the initial size of the heap on startup. If the initial heap size
|
|
|
is not equal to the maximum heap size, after a resize it will not be the
|
|
|
case that all of the JVM heap is locked in memory. To pass the heap size
|
|
@@ -62,11 +62,11 @@ Elasticsearch would much rather use to service requests. There are
|
|
|
several ways to configure a system to disallow swapping. One way is by
|
|
|
requesting the JVM to lock the heap in memory through `mlockall` (Unix)
|
|
|
or virtual lock (Windows). This is done via the Elasticsearch setting
|
|
|
-<<bootstrap.mlockall,`bootstrap.mlockall`>>. However, there are cases
|
|
|
+<<bootstrap.memory_lock,`bootstrap.memory_lock`>>. However, there are cases
|
|
|
where this setting can be passed to Elasticsearch but Elasticsearch is
|
|
|
not able to lock the heap (e.g., if the `elasticsearch` user does not
|
|
|
have `memlock unlimited`). The memory lock check verifies that *if* the
|
|
|
-`bootstrap.mlockall` setting is enabled, that the JVM was successfully
|
|
|
+`bootstrap.memory_lock` setting is enabled, that the JVM was successfully
|
|
|
able to lock the heap. To pass the memory lock check, you might have to
|
|
|
configure <<mlockall,`mlockall`>>.
|
|
|
|