Почему использование памяти контейнера упругого поиска растет с небольшим использованием? - PullRequest
Новая
       29

Почему использование памяти контейнера упругого поиска растет с небольшим использованием?

5 голосов
/ 14 марта 2019

Я развернул поисковый контейнер Elastic в aws, используя кластер eks kubernetes.Использование памяти контейнера продолжает увеличиваться, хотя есть только 3 индекса, и они не используются интенсивно.Я сбрасываю логи кластерного контейнера в эластичный поиск, используя FluentD.Кроме этого, нет использования упругого поиска.Я попытался применить минимальный / максимальный размер кучи, используя -Xms512m -Xmx512m.Это успешно применяется, но, тем не менее, использование памяти почти удвоилось за 24 часа.Я не уверен, какие другие опции мне нужно настроить.Я попытался изменить образ докера с elasticsearch:6.5.4 на elasticsearch:6.5.1.Но проблема сохраняется.Я также попробовал -XX:MaxHeapFreeRatio=50 вариант Java.

Проверьте скриншот с кибана.enter image description here

Редактировать: Ниже приведены журналы запуска Elastic-поиска: 

[2019-03-18T13:24:03,119][WARN ][o.e.b.JNANatives         ] [es-79c977d57-v77gw] Unable to lock JVM Memory: error=12, reason=Cannot allocate memory
[2019-03-18T13:24:03,120][WARN ][o.e.b.JNANatives         ] [es-79c977d57-v77gw] This can result in part of the JVM being swapped out.
[2019-03-18T13:24:03,120][WARN ][o.e.b.JNANatives         ] [es-79c977d57-v77gw] Increase RLIMIT_MEMLOCK, soft limit: 16777216, hard limit: 16777216
[2019-03-18T13:24:03,120][WARN ][o.e.b.JNANatives         ] [es-79c977d57-v77gw] These can be adjusted by modifying /etc/security/limits.conf, for example: 
    # allow user 'elasticsearch' mlockall
    elasticsearch soft memlock unlimited
    elasticsearch hard memlock unlimited
[2019-03-18T13:24:03,120][WARN ][o.e.b.JNANatives         ] [es-79c977d57-v77gw] If you are logged in interactively, you will have to re-login for the new limits to take effect.
[2019-03-18T13:24:03,397][INFO ][o.e.e.NodeEnvironment    ] [es-79c977d57-v77gw] using [1] data paths, mounts [[/usr/share/elasticsearch/data (/dev/xvda1)]], net usable_space [38.6gb], net total_space [96.8gb], types [ext4]
[2019-03-18T13:24:03,397][INFO ][o.e.e.NodeEnvironment    ] [es-79c977d57-v77gw] heap size [503.6mb], compressed ordinary object pointers [true]
[2019-03-18T13:24:03,469][INFO ][o.e.n.Node               ] [es-79c977d57-v77gw] node name [es-79c977d57-v77gw], node ID [qrCUCaHoQfa3SXuTpLjUUA]
[2019-03-18T13:24:03,469][INFO ][o.e.n.Node               ] [es-79c977d57-v77gw] version[6.5.1], pid[1], build[default/tar/8c58350/2018-11-16T02:22:42.182257Z], OS[Linux/4.15.0-1032-aws/amd64], JVM[Oracle Corporation/OpenJDK 64-Bit Server VM/11.0.1/11.0.1+13]
[2019-03-18T13:24:03,469][INFO ][o.e.n.Node               ] [es-79c977d57-v77gw] JVM arguments [-Xms1g, -Xmx1g, -XX:+UseConcMarkSweepGC, -XX:CMSInitiatingOccupancyFraction=75, -XX:+UseCMSInitiatingOccupancyOnly, -XX:+AlwaysPreTouch, -Xss1m, -Djava.awt.headless=true, -Dfile.encoding=UTF-8, -Djna.nosys=true, -XX:-OmitStackTraceInFastThrow, -Dio.netty.noUnsafe=true, -Dio.netty.noKeySetOptimization=true, -Dio.netty.recycler.maxCapacityPerThread=0, -Dlog4j.shutdownHookEnabled=false, -Dlog4j2.disable.jmx=true, -Djava.io.tmpdir=/tmp/elasticsearch.oEmM9oSp, -XX:+HeapDumpOnOutOfMemoryError, -XX:HeapDumpPath=data, -XX:ErrorFile=logs/hs_err_pid%p.log, -Xlog:gc*,gc+age=trace,safepoint:file=logs/gc.log:utctime,pid,tags:filecount=32,filesize=64m, -Djava.locale.providers=COMPAT, -XX:UseAVX=2, -Des.cgroups.hierarchy.override=/, -Xms512m, -Xmx512m, -Des.path.home=/usr/share/elasticsearch, -Des.path.conf=/usr/share/elasticsearch/config, -Des.distribution.flavor=default, -Des.distribution.type=tar]
[2019-03-18T13:24:05,082][INFO ][o.e.p.PluginsService     ] [es-79c977d57-v77gw] loaded module [aggs-matrix-stats]
[2019-03-18T13:24:05,082][INFO ][o.e.p.PluginsService     ] [es-79c977d57-v77gw] loaded module [analysis-common]
[2019-03-18T13:24:05,082][INFO ][o.e.p.PluginsService     ] [es-79c977d57-v77gw] loaded module [ingest-common] ....

1 Ответ

1 голос
/ 15 марта 2019

Использование памяти Pod в Kubernetes не эквивалентно использованию памяти JVM - чтобы получить эту статистику, вам нужно было бы напрямую извлечь метрику из JVM. Использование памяти модуля в зависимости от запрашиваемой метрики может также включать кэш страницы и пространство подкачки, в дополнение к памяти приложения, поэтому на графике, который вы указали, не указано, что на самом деле потребляет память. В зависимости от проблемы Elasticsearch имеет расширенные функции, такие как блокировка памяти , которая блокирует адресное пространство вашего процесса в оперативной памяти. Тем не менее, верный способ удержать модуль Kubernetes от потребления памяти не-JVM - это просто установить ограничение на количество памяти, которое может использовать этот модуль. В вашей спецификации модуля Kubernetes установите resources.limits.memory на желаемое ограничение памяти, и потребление памяти не превысит этого предела. Конечно, если это проблема с вашей конфигурацией JVM, модуль ES завершится с ошибкой OOM, когда достигнет предела. Просто убедитесь, что вы выделяете дополнительное пространство для системных ресурсов, и я имею в виду, что ваш предел памяти модуля должен быть несколько больше, чем ваш максимальный размер кучи JVM.

С другой стороны, вы можете быть удивлены тем, как много работы Kubernetes ведет за кулисами. Периодически закрывайте индексы Elasticsearch , которые не регулярно ищутся для освобождения памяти.

...