Как правило, файлы Snap*trc используются службой поддержки, а не клиентами. Они содержат любые данные трассировки, хранящиеся в памяти на момент создания дампа. Они могут быть полезны в некоторых случаях OOM для проверки, например, возникла ли OOM из-за исчерпания собственной памяти. Кажется, вы уже выяснили, как их отформатировать, и полученный текстовый файл *trc.fmt представляет собой просто набор точек трассировки, поэтому он аналогичен анализу любой трассировки (что обычно означает, что вам нужно понять код и, следовательно, почему Snap*trc файлы, как правило, ограничены для использования службой поддержки). Вы можете найти немного больше информации о файлах Snap здесь: https://publib.boulder.ibm.com/httpserv/cookbook/Troubleshooting-Troubleshooting_Java-Troubleshooting_IBM_Java.html#Troubleshooting-Troubleshooting_IBM_Java-Snap_Traces
С учетом сказанного, в общем, вот как я анализирую OOM:
- Посмотрите на
1TISIGINFO в файле javacore*txt. Это скажет вам, является ли это OOM Java или нативным OOM.
- Если это Java OOM, загрузите файл
core*dmp в IBM Memory Analyzer Tool . Обратите внимание, что другой вопрос, на который вы ссылались, говорит, что вы должны запустить jextract в файле core*dmp, чтобы проанализировать его, и это больше не относится к последним версиям Java - просто загрузите файл core*dmp в инструмент IBM MAT .
- Если это нативный OOM, тогда это становится более сложным, поэтому вы можете отправить сюда подробности.
Как всегда, вы также можете открыть службу поддержки в IBM, и они могут помочь вам в этом анализе.