Подскажите, корректно ли такое функционирование gc.log

[Vivaldy (Vladimir Yegudin)]

В gc.log наблюдаю такую картину

[2019-12-09T07:04:18.772+0000][23226][gc] Using Concurrent Mark Sweep
[2019-12-09T07:04:18.772+0000][23226][gc,heap,coops] Heap address: 0x00000000c0000000, size: 1024 MB, Compressed Oops mode: 32-bit
[2019-12-09T07:04:18.822+0000][23226][safepoint ] Entering safepoint region: EnableBiasedLocking
[2019-12-09T07:04:18.822+0000][23226][safepoint ] Leaving safepoint region
[2019-12-09T07:04:18.822+0000][23226][safepoint ] Total time for which application threads were stopped: 0,0004150 seconds, Stopping threads took: 0,0003539 seconds
[2019-12-09T07:04:18.825+0000][23226][safepoint ] Application time: 0,0031908 seconds
[2019-12-09T07:04:18.825+0000][23226][safepoint ] Entering safepoint region: RevokeBias
[2019-12-09T07:04:18.825+0000][23226][safepoint ] Leaving safepoint region
[2019-12-09T07:04:18.825+0000][23226][safepoint ] Total time for which application threads were stopped: 0,0000852 seconds, Stopping threads took: 0,0000251 seconds
[2019-12-09T07:04:18.834+0000][23226][safepoint ] Application time: 0,0090609 seconds

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

[Igor_Motov]

А что с хипом-то происходит?

[Vivaldy (Vladimir Yegudin)]

Эм, а где это глянуть?

[Igor_Motov]

А чем у вас узлы мониторятся?

[Vivaldy (Vladimir Yegudin)]

Эм, я если честно не знаю. Нода у меня одна и один сервер. Стоит по сути стандартная вся конфигурация.

[Igor_Motov]

Можно настроить monitoring, либо смотреть во время запуска этой программы через stats.

[Vivaldy (Vladimir Yegudin)]

запустил мониторинг
Еластик так же встал ночью
В мониторинге такая картина:

Правда вкладка с мониторингом не была открыта - он не обновлялся

[Igor_Motov]

И что с хипом ночью происходило (надо на Nodes: 1) нажать, потом на ноду и потом на график heap посмотреть).

[Vivaldy (Vladimir Yegudin)]

Вот такая картина. Вот он примерно в 1:20 упал и в 11:20 я добрался и рестартанул его.

Из того что менялось когда стало падать.
Там systemd следит за функционированием PHP скрипта который делает обработку (он лишь подключается к эластику, но его никак не трогает) вот для него задание выставляется на работу в 1:15. Раньше ничего не подало, а сейчас стало каждый день. в итоге и выполнение этих скриптов отваливается. Я сейчас сделал так чтоб коннекта не было - проверю сработает или упадет.

[Igor_Motov]

А можно на логи посмотреть? И это какая ОС?

[Vivaldy (Vladimir Yegudin)]

Ubuntu 16.04
логи из какого файла?

[Igor_Motov]

Если Ubuntu, посмотрите dmesg | grep oom-killer. И пришлите лог elasticsearch.log (если у вас кластер elasticsearch называется).

[Vivaldy (Vladimir Yegudin)]

@Igor_Motov

dmesg | grep oom-killer

вот что выдало:
[1241038.385466] php invoked oom-killer: gfp_mask=0x24201ca, order=0, oom_score_adj=0
[1241039.825384] fail2ban-server invoked oom-killer: gfp_mask=0x24201ca, order=0, oom_score_adj=0
[1327440.340947] mysqld invoked oom-killer: gfp_mask=0x24201ca, order=0, oom_score_adj=0
[1327449.187594] mysqld invoked oom-killer: gfp_mask=0x24201ca, order=0, oom_score_adj=0
[1500218.349604] elasticsearch[m invoked oom-killer: gfp_mask=0x24201ca, order=0, oom_score_adj=0
[1500231.325909] nginx invoked oom-killer: gfp_mask=0x24201ca, order=0, oom_score_adj=0
[1545554.027030] node invoked oom-killer: gfp_mask=0x24201ca, order=0, oom_score_adj=0
[1545554.030316] ml-cpp-log-tail invoked oom-killer: gfp_mask=0x24201ca, order=0, oom_score_adj=0

а лог наверно завтра или послезавтра попробую - я сегодня отключил коннект к эластику именно в модулях которые запускаются в то время когда все падает, но в остальных местах все осталось - посмотрю что будет.
А лог который был за вчера - не сохранил ((

[Igor_Motov]

У вас на этой машине слишком много всего запущено. Памяти не хватает. Поэтому oom-killer и регулярно вырубает один из процессов. Иногда этот процесс - elasticsearch.