Сбой приложения Springboot на Cloud Foundry без каких-либо журналов сбоев - PullRequest
Новая
       35

Сбой приложения Springboot на Cloud Foundry без каких-либо журналов сбоев

1 голос
/ 27 сентября 2019

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

Я попытался добавить следующие параметры Java с результатами, как указано выше: -XX: ErrorFile: файл не был создан при ошибке -XX: + HeapDumpOnOutOfMemoryError: Создан дамп кучикогда происходит сбой экземпляра.

Дамп кучи создается при сбое экземпляра, но нет журналов OOM.

Я также попытался добавить встроенные журналы tomcat для приложения весенней загрузки со следующими добавленными пакетами: org.apache.tomcat, org.apache.catalina, org.apache.coyote.Попытался создать OOM локально в Docker и увидел, что журнал OOM поступает в журналы tomcat для приложения.

Просто чтобы уточнить, Проблема в том, как определить, какой компонент памяти отвечает за OOM?

Ответы [ 2 ]

0 голосов
/ 27 сентября 2019

Когда вы запускаете свои Java-приложения в Cloud Foundry, использование -XX:+HeapDumpOnOutOfMemoryError не поможет.Добавление этой опции вызовет дамп кучи, но он будет записан в контейнере вашего приложения.Как только это закончится, контейнер уйдет, и вы не сможете получить файл, который был написан.

Чтобы сделать это на Cloud Foundry, Java buildpack предоставляет некоторую помощь.

  1. Java buildpack настраивает киллагент , который добавляется в JVM.Этот агент будет выполняться при возникновении ошибки OutOfMemoryError.Он напечатает гистограмму использования памяти, а также распечатает сводку памяти.Вы увидите это в выходных данных cf logs.

    Пример: 

    Resource exhaustion event: the JVM was unable to allocate memory from the heap.
ResourceExhausted! (1/0)
| Instance Count | Total Bytes | Class Name                                    |
| 18273          | 313157136   | [B                                            |
| 47806          | 7648568     | [C                                            |
| 14635          | 1287880     | Ljava/lang/reflect/Method;                    |
| 46590          | 1118160     | Ljava/lang/String;                            |
| 8413           | 938504      | Ljava/lang/Class;                             |
| 28573          | 914336      | Ljava/util/concurrent/ConcurrentHashMap$Node; |

    и 

     Memory usage:
   Heap memory: init 65011712, used 332392888, committed 351797248, max 351797248
   Non-heap memory: init 2555904, used 63098592, committed 64815104, max 377790464
Memory pool usage:
   Code Cache: init 2555904, used 14702208, committed 15007744, max 251658240
   PS Eden Space: init 16252928, used 84934656, committed 84934656, max 84934656
   PS Survivor Space: init 2621440, used 0, committed 19398656, max 19398656
   Compressed Class Space: init 0, used 5249512, committed 5505024, max 19214336
   Metaspace: init 0, used 43150616, committed 44302336, max 106917888
   PS Old Gen: init 43515904, used 247459792, committed 247463936, max 247463936

    Все приложения Java получают это при запуске с использованием Java buildpackна Cloud Foundry, и это может быть полезно для понимания использования памяти при сбое вашего приложения.Если вы этого не видите, значит ваше приложение зависло по какой-то другой причине (см. Ниже).

  2. Если вам нужно больше узнать об использовании памяти, вы можете получить полный дамп кучи.Для этого вам необходимо привязать постоянное хранилище к вашему приложению.Если вы привязываете службу томов к своему приложению, имя которой содержит heap-dump, то пакет сборки Java настроит это хранилище для автоматического использования для захвата дампов кучи.

    Если томСлужба со строкой heap-dump в своем имени или теге привязана к приложению, дампы кучи терминала будут записываться с шаблоном <CONTAINER_DIR>/<SPACE_NAME>-<SPACE_ID[0,8]>/<APPLICATION_NAME>-<APPLICATION_ID[0,8]>/<INSTANCE_INDEX>-<TIMESTAMP>-<INSTANCE_ID[0,8]>.hprof

Если вывы не видите выходных данных из киллингвента JVM или не видите дампов кучи, сгенерированных в вашем постоянном хранилище:

  1. Убедитесь, что агент JVM был добавлен.Когда buildpack запускается во время подготовки, вы должны увидеть загруженный и установленный killagent.
  2. Он также должен отображаться в команде запуска, генерируемой Java buildpack.Проверьте команду запуска, чтобы убедиться, что вы видите агента.Обратите внимание, что пакет сборки не сможет добавить агента, если вы укажете собственную команду запуска с помощью cf push -c.
  3. Вы просто не испытываете ошибку OutOfMemoryError.Вполне возможно, что ваше приложение падает по какой-то другой причине.Чаще всего вы превышаете предел памяти контейнера, а не предел памяти JVM.В этом случае контейнер немедленно рухнет, и вы не получите вывод от убийцы.

Надеюсь, это поможет!

0 голосов
/ 27 сентября 2019

По умолчанию дамп кучи создается в файле с именем java_pidpid.hprof в рабочем каталоге виртуальной машины.Вы можете указать альтернативное имя файла или каталог с помощью опции -XX: HeapDumpPath =.См. https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/clopts001.html для настроек горячей остановки Java

...