Зависает процесс эластика

[Андрей Шатохин]

Добрый день! 

java version "1.7.0_55"

elasticsearch Version: 1.4.4

СPU E5-2620 v3 х2. Всего 64Гб памяти. Параметры запуска -Xms28G -Xmx28G -Xss256k. 

Переодически зависает процесс эластика. При этом не реагирует вообще ни на что. Не отвечает по http. Не реагирует на kill.   Завершается только по kill -9. 

В логах переодически подобное

[2015-03-10 12:38:49,794][WARN ][monitor.jvm              ] [baby-e3] [gc][young][6419][652] duration [1.5s], collections [1]/[1.8s], total [1.5s]/[11.9m], memory [19.8gb]->[19.5gb]/[27.8gb], all_pools {[young] [988.5mb]->[54.4mb]/[1.1gb]}{[survivor] [149.7mb]->[149.7mb]/[149.7mb]}{[old] [18.7gb]->[19.3gb]/[26.5gb]}

Всего нод 3. Пробывал добавлять еще одну. Пробывали  версию 1.3.7 - не помогает.  Единственное что заметил - зависает когда должен очищать HEAP. http://joxi.ru/nAy9qqJU3BK5AZ

Пробывал давать ему как больше памяти (до 48Гб) и меньше (от 18 Гб)

[Igor Motov]

Такое бывает от плохих плагинов которые сорят памятью, либо когда процесс elasticsearch уходит в swap. Попробуйте настроить elasticsearch как описано тут https://www.elastic.co/guide/en/elasticsearch/reference/current/setup-configuration.html#setup-configuration-memory

[Андрей Шатохин]

Спасибо за ответ.  

из плагинов у нас: 

    "plugins" : [ {
      "name" : "lang-mvel",
      "version" : "1.4.1",
      "description" : "MVEL plugin allowing to add MVEL scripting support",
      "jvm" : true,
      "site" : false
    }, {
      "name" : "marvel",
      "version" : "1.3.1",
      "description" : "Elasticsearch Management & Monitoring",
      "url" : "/_plugin/marvel/",
      "jvm" : true,
      "site" : true
    }, {
      "name" : "analysis-morphology",
      "version" : "NA",
      "description" : "Morphology analysis support",
      "jvm" : true,
      "site" : false
    } ]

Swap разделов на серверах нет вообще.

Mlockall везде был(и есть) включен.

Из инструкции по ссылке не было только sysctl -w vm.max_map_count=262144, что я сейчас и добавил. Посмотрим как работать будет

вторник, 10 марта 2015 г., 18:59:08 UTC+1 пользователь Igor Motov написал:

[Андрей Шатохин]

Итог - проработал сервер примерно 2 часа и завис процесс java.  За сутки успел попробовать сменить версию java (OpenJDK7, Oracle7-8). Успеха так и нет. Из наблюдений - подключил к кастеру более слабые ноды(E3-1270 v3 х1 + 32Gb ram, HEAP 14Gb) - на них все работает стабильно и не падает.  Нет никакой зависимости от многоядерности( многопроцессорности?), или от размера ram в системе?

вторник, 10 марта 2015 г., 21:04:53 UTC+1 пользователь Андрей Шатохин написал:

[Igor Motov]

Какая ОС стоит на этих машинах и какая версия ядра?  Я смутно помню 2.6.32 что подобное выкидывало.

[Андрей Шатохин]

gentoo

# uname -a

Linux baby-e3 3.15.10-hardened-r1 #1 SMP Thu Feb 5 18:04:03 MSK 2015 x86_64 Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz GenuineIntel GNU/Linux

четверг, 12 марта 2015 г., 0:35:41 UTC+1 пользователь Igor Motov написал:

[Кирш Николай]

Попробуй для эксперимента отключить плагин "analysis-morphology", у меня с ним тоже в логах подобные сообщения и зависания.

Подробное описание есть на странице проекта, https://github.com/imotov/elasticsearch-analysis-morphology/issues/17 , но там уже вторую неделю тишина.

вторник, 10 марта 2015 г., 14:10:09 UTC+5 пользователь Андрей Шатохин написал:

[Igor Motov]

Забавно, похоже я что-то с нотификацией напутал, или каким-то образом github "решил", что меня эта проблема просто не интересует и ничего мне не прислал. Спасибо, что подтолкнули. Буду сегодня разбираться и с нотификацией и с памятью.

Однако, в случае с проблемой описанной на github сборка старого поколения занимает много времени, что, хоть и не хорошо, но объяснимо. У Андрея сборка молодого поколения занимает 1.5 сек! 

[Igor Motov]

Может быть это https://groups.google.com/forum/#!msg/mechanical-sympathy/QbmpZxp6C64/BonaHiVbEmsJ ?

[Андрей Шатохин]

Да верно. Мы в итоге и сменили ветку ядра с 3.15 до ветки 3.18. И это нам помогло. Осталась потом проблема плохого мапинга, но ее решат со временем.

Интересно что проблемы не было на более слабых нодах, хотя ядро мы всегда и везде держим одинаковым.

четверг, 14 мая 2015 г., 19:34:41 UTC+2 пользователь Igor Motov написал:

[Igor Motov]

Похоже, что не все железо страдает от этой проблемы. Народ грешит на Haswell, но никто точно не знает, какие именно системы подвержены этим проблемам. Исходя из вашего опыта ни в одном Haswell тут дело.

[Андрей Шатохин]

У нас получается совсем наоборот на простых  Haswell все работало и на ядре с багом. А вот на Haswell-EP уже зависало.

четверг, 14 мая 2015 г., 20:39:43 UTC+2 пользователь Igor Motov написал: