elasticsearchのコンテナが137エラーで立ち上がらない #Elasticsearch

はじめに

elasticsearchでdockerコンテナを立ち上げても下記のエラーで立ち上がらないので、原因＆解消方法を探る

elasticsearch exited with code 137

dockerfile

services:
  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:7.1.1
    expose:
      - 9200
    ports:
      - "9200:9200"
      - "9300:9300"
    tty: true
    environment:
      discovery.type: single-node

エラーコード137とは

OOM（メモリが足りない）が原因で、コンテナがSIGKILLされているようだ
https://success.docker.com/article/what-causes-a-container-to-exit-with-code-137

OOM状態の処理に関しては、ノードのカーネルログを確認してみる

journalctl -k | grep -i -e memory -e oom
# 実行結果
Out of memory: Kill process 19824 (java) score 116 or sacrifice child

もしくは落ちてしまったコンテナの詳細をみることもできる

docker inspect <container ID>

メモリの上限を設定する

公式のリファレンスに書いてある
https://www.elastic.co/guide/en/elasticsearch/reference/current/heap-size.html

起動時のヒープサイズと最大ヒープサイズは物理メモリによって決める
起動時のヒープサイズと最大ヒープサイズは物理メモリの50%以下に設定するといいみたい
Xmx設定で構成された制限よりも多くのメモリを使用してElasticsearchプロセスを監視する必要がある

では、自分の環境で物理メモリはどれくらいあるか見てみると

free -m
# 実行結果
              total        used        free      shared  buff/cache   available
Mem:           7803        5325         536         163        1940        1816
Swap:          4095        2221        1874

１GBまでならelasticsearchのコンテナに当てられそう

では、実際に起動時のヒープサイズと最大ヒープサイズを設定する
ES_JAVA_OPTSの環境変数に値をセットすればいい

と、その前にヒープ領域に関して簡単に復習

ヒープメモリ

大きくつの領域がある

new領域（短命なオブジェクト）
old領域（長生きオブジェクト）
permanent領域（クラスを保持する）

さらに、new領域にはeden、from、toの3つの領域があり、edenがいっぱいになったら、fromもしくはto領域にオブジェクトを移動する
そしてさらに、移動回数が多いオブジェクトはold領域へ移動する

GC

ヒープ領域を掃除するGCについても大きく2つタイプがある

Scavenge GC（NEW領域のみを対象とした短時間で終了するガベージ・コレクションであり、頻繁に実施）
Full GC（NEWとOLD両方の領域を対象とした大がかりなガベージ・コレクションであり、比較的低い頻度で実施）

（参考： https://www.atmarkit.co.jp/ait/articles/0504/02/news005_2.html）

本題に戻ってヒープ領域を制限する

ES_JAVA_OPTSでXmsとXmxをそれぞれ500MBで設定する

dockerfile

services:
  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:7.1.1
    expose:
      - 9200
    ports:
      - "9200:9200"
      - "9300:9300"
    tty: true
    environment:
      discovery.type: single-node
      ES_JAVA_OPTS: -Xms500m -Xmx500m

そして、実際にメモリ使用量が減ったか見てみると

変更前

ps aux | grep elastic
# 実行結果
1000     115726  1.2 16.6 4803048 1329072 pts/0 Ssl+ 13:51   7:01 /usr/share/elasticsearch/jdk/bin/java -Xms1g -Xmx1g ・・・ override=/ -Xms1g -Xmx1g ・・・

変更後

ps aux | grep elastic
# 実行結果
1000      27147  231  9.4 3789796 753308 pts/0  Ssl+ 23:41   0:23 /usr/share/elasticsearch/jdk/bin/java -Xms1g -Xmx1g ・・・ override=/ -Xm500m -Xmx500m ・・・

変更後の方は、XmsとXmxの値がoverrideされて、
変更前はメモリ使用率が16.6%だったのが、9.4%まで落ちているのがわかる！
これでOOMで落ちることはない！

Let's start programming elasticsearch!!