Skip to content

Commit

Permalink
Add section about virtual memory to Elasticsearch doc (#1214)
Browse files Browse the repository at this point in the history
* Add initial description for setting virtual memory

* Update elasticsearch-spec.asciidoc
  • Loading branch information
artemnikitin authored Jul 15, 2019
1 parent 8c2a798 commit 691e693
Showing 1 changed file with 34 additions and 1 deletion.
35 changes: 34 additions & 1 deletion docs/elasticsearch-spec.asciidoc
Original file line number Diff line number Diff line change
Expand Up @@ -101,6 +101,38 @@ $ openssl req -x509 -newkey rsa:4096 -keyout tls.key -out tls.crt -days 365 -nod
$ kubectl create secret tls my-cert --cert tls.crt --key tls.key
----

[id="{p}-virtual-memory"]
=== Virtual memory

By default, Elasticsearch is using memory mapping (mmap) to efficiently access indices.
Usually, default values for virtual address space on Linux distributions are too low for Elasticsearch to work properly, which may result in out of memory exceptions.
To increase virtual memory ECK sets the recommended value by default.

A dedicated init container will set the kernel setting `vm.max_map_count=262144` on the host.
This requires the init container to be privileged.
This kernel setting can also be set on the host directly.
In such case, you may disable the init container explicitly in the Elasticsearch specification:
[source,yaml]
----
spec:
setVmMaxMapCount: false
----

To get more info about this setting you can consult the Elasticsearch documentation:
https://www.elastic.co/guide/en/elasticsearch/reference/current/vm-max-map-count.html

Optionally, you can select a different type of file system implementation for the storage. Here you can find information about possible options:
https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules-store.html

[source,yaml]
----
spec:
nodes:
- nodeCount: 3
config:
index.store.type: niofs
----

[id="{p}-update-strategy"]
=== Update strategy

Expand Down Expand Up @@ -237,4 +269,5 @@ ECK will detect it, and recreate the 3 missing nodes as expected. However, since
In this situation, it would be preferable to first recreate the missing nodes in `europe-west-3b`, then continue the cluster upgrade.

In order to do so, ECK must know about the logical grouping of nodes. Since this is an arbitrary setting (can represent availability zones, but also nodes roles, hot-warm topologies, etc.), it must be specified in the `updateStrategy.groups` section of the Elasticsearch specification.
Nodes grouping is expressed through labels on the resources. In the example above, 3 pods are labeled with `group-a`, and the 3 other pods with `group-b`.
Nodes grouping is expressed through labels on the resources. In the example above, 3 pods are labeled with `group-a`, and the 3 other pods with `group-b`.

0 comments on commit 691e693

Please sign in to comment.