Подтвердить что ты не робот

Запуск jmap получение Не удалось открыть файл сокета

Мне пришлось запустить jmap, чтобы взять кучу моего куча. но jvm возвращается:

Unable to open socket file: target process not responding or HotSpot VM not loaded
The -F option can be used when the target process is not responding

Итак, я использовал -F:

./jmap -F -dump:format=b,file=heap.bin 10330
Attaching to process ID 10331, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 24.51-b03
Dumping heap to heap.bin ...
  • Использование -F подходит для получения дампа кучи?
  • Я жду 20 минут и еще не закончен. Любые идеи, почему?
4b9b3361

Ответ 1

jmap vs. jmap -F, а также jstack vs. jstack -F используют совершенно разные механизмы для коммутации с целевой JVM.

jmap/jstack

При запуске без -F эти инструменты используют Dynamic Attach Mechanism. Это работает следующим образом.

  • Перед подключением к Java-процессу 1234, jmap создает файл .attach_pid1234 в рабочем каталоге целевого процесса или в /tmp.

  • Затем jmap отправляет SIGQUIT в целевой процесс. Когда JVM захватывает сигнал и находит .attach_pid1234, он запускает поток AttachListener.

  • AttachListener thread создает дочерний домен UNIX /tmp/.java_pid1234 для прослушивания команд из внешних инструментов.

  • По соображениям безопасности, когда соединение (из jmap) принято, JVM проверяет, что учетные данные сокета равны euid и egid процесса JVM. Поэтому jmap не будет работать, если его запускают разные пользователи (даже root).

  • jmap подключается к сокету и отправляет команду dumpheap.

  • Эта команда считывается и выполняется потоком AttachListener JVM. Весь вывод отправляется обратно в сокет. Поскольку дамп кучи выполняется непосредственно JVM, операция выполняется очень быстро. Однако JVM может сделать это только в safepoints. Если невозможно достигнуть точки безопасности (например, процесс зависает, не отвечает или длится GC), jmap будет тайм-аут и сбой.

Обобщите преимущества и недостатки Dynamic Attach.

Pros.

  • Дамп кучи и другие операции выполняются совместно JVM с максимальной скоростью.
  • Вы можете использовать любую версию jmap или jstack для подключения к любой другой версии JVM.

Cons.

  • Инструмент должен запускаться одним и тем же пользователем (euid/egid) в качестве целевой JVM.
  • Может использоваться только для живых и здоровых JVM.
  • Не работает, если целевая JVM запущена с помощью -XX:+DisableAttachMechanism.

jmap -F/jstack -F

При запуске с помощью -F инструменты переключаются в специальный режим, в котором агент HotSpot Serviceability Agent. В этом режиме целевой процесс заморожен; инструменты считывают свою память через средства отладки ОС, а именно ptrace в Linux.

  • jmap -F вызывает PTRACE_ATTACH на целевой JVM. Целевой процесс безоговорочно приостанавливается в ответ на сигнал SIGSTOP.

  • Инструмент считывает JVM-память с помощью PTRACE_PEEKDATA. ptrace может читать только одно слово за раз, поэтому слишком много вызовов требуется для чтения большой кучи целевого процесса. Это очень и очень медленно.

  • Инструмент восстанавливает внутренние структуры JVM на основе знания конкретной версии JVM. Поскольку разные версии JVM имеют разный формат памяти, режим -F работает, только если jmap поступает из одного JDK в качестве целевого Java-процесса.

  • Инструмент создает сам кучу кучи, а затем возобновляет целевой процесс.

Pros.

  • Сотрудничество с целевой JVM не требуется. Может использоваться даже при зависании.
  • ptrace работает, когда достаточно привилегий на уровне ОС. Например. root может сбрасывать процессы всех других пользователей.

Cons.

  • Очень медленно для больших куч.
  • Инструмент и целевой процесс должны быть из той же версии JDK.
  • Нельзя гарантировать, что safepoint не будет использоваться, если инструмент подключается в принудительном режиме. Хотя jmap пытается обрабатывать все особые случаи, иногда может случиться, что целевая JVM не находится в согласованном состоянии.

Примечание

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

Ответ 2

Я только что обнаружил, что jmap (и, предположительно, jvisualvm при использовании его для создания дампа кучи) предусматривает, что пользователь, запускающий jmap, должен быть тем же пользователем, который запускает процесс, пытающийся сбрасываться.

в моем случае jvm я хочу, чтобы куча дампа была запущена пользователем linux "jboss". поэтому, когда sudo jmap -dump:file.bin <pid> сообщал "Не удалось открыть сокет:", я смог захватить мой кучи с помощью:

sudo -u jboss jmap -dump:file.bin <pid>

Ответ 3

Как и ben_wing, вы можете работать с:

sudo -u jboss-as jmap -dump:file.bin <pid>

(в моем случае пользователь jboss-as, но ваш может быть jboss или какой-либо другой.)

Но этого было недостаточно, потому что он попросил меня пароль ([sudo] password for ec2-user:), хотя я мог запустить sudo, не запрашивая пароль для других команд.

Я нашел решение здесь, и мне просто нужно было сначала добавить еще sudo:

sudo sudo -u jboss-as jmap -dump:file.bin <pid>

Он работает с другими командами, такими как jcmd и jinfo.