Java-процесс с высоким I / O последовательно получает сигнал 11 SIGSEGV в JavaThread при запуске в контейнере Docker

Question

Кто-нибудь был в состоянии последовательно реплицировать SIGSEGV на JRE, используя различное оборудование и разные версии JRE?Примечание (потенциально большое примечание): я запускаю процесс в контейнере Docker, развернутом в Kubernetes.

Пример ошибки:

# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007fea64dd9d01, pid=21, tid=0x00007fe8dfbfb700
#
# JRE version: Java(TM) SE Runtime Environment (8.0_191-b12) (build 1.8.0_191-b12)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.191-b12 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# J 8706 C2 com.fasterxml.jackson.core.json.ReaderBasedJsonParser.nextFieldName()Ljava/lang/String; (493 bytes) @ 0x00007fea64dd9d01 [0x00007fea64dd9b60+0x1a1]

В настоящее время я управляю процессом с высоким вводом-выводому этого есть много потоков, делающих ввод / вывод и сериализацию: загрузка CSV и JSON, чтение CSV, запись JSON в CSV и загрузка CSV в MySQL.Я делаю это тысячи раз в течение цикла выполнения приложения.Я использую только обычные библиотеки (Jackson, jOOQ) и «обычный» код: в частности, я не писал собственный код, использующий JNI.

Обязательно, JVM будет SIGSEGV во время каждого цикла работы.Это кажется SIGSERV в различных частях базы кода, но никогда в GC-потоке или любых других известных потоках.«Проблемный кадр» - это всегда скомпилированный код.

Спецификации тестирования:

• Несколько различных аппаратных экземпляров в AWS.
• Протестировано с использованием Java 8 191 и 181. Ubuntu16,04.
• Этот процесс выполняется в контейнере (Docker) и развернут в Kubernetes.
• Версия Docker: 17.03.2-ce

Вот полный журнал: https://gist.github.com/navkast/9c95f56ce818d76276684fa5bb9a6864

Answer 1

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

Некоторые сведения о том, как запустить JVM в контейнере здесь.

Вы не опубликовали никаких спецификаций для стручков, но вы также можете посмотреть пределы настроек для ваших Kubernetes pods .

Answer 2

Здесь есть большая подсказка

 Memory: 4k page, physical 33554432k(1020k free), swap 0k(0k free)

Из 32 ГБ только 1 МБ свободно на момент сбоя.Скорее всего, процесс был убит, так как системе не хватило памяти.Я предлагаю:

• значительно уменьшить размер кучи.например, 2 - 8 ГБ
• увеличение доступной памяти.например, 4 - 16 ГБ
• с добавлением некоторого пространства подкачки.например, 8 - 32 ГБ, это не решит проблему, но будет обрабатывать всю память немного более изящно.

Answer 3

Из полного журнала:

siginfo: si_signo: 11 (SIGSEGV), si_code: 0 (SI_USER)

Это означает, что kill() было выдано.Это не проблема JVM.Что-то умышленно убивает процесс.Вероятно, из-за нехватки памяти.