Сбор дампа кучи Java через приложение

У нас есть сервер приложений Java, который выполняет обработку аудио / видео в реальном времени, и для этого он потребляет много памяти (25+ ГБ ОЗУ). Из-за некоторой, пока неизвестной ошибки в нашем JNI, время от времени происходит сбой нашей JVM.

Наш сервер работает на Ubuntu 16.04.2 LTS и когда наша JVM падает, она ведет себя очень странно. Он начинает сбрасывать кучу свалки в /var/crash, он достигает размера ~1,4 ГБ (сжатый) и останавливается, перезаписывая дамп кучи с 50 КБ данных.

Журнал приложений:

ERROR: apport (pid 30913) Tue Oct 23 12:38:49 2018: called for pid 29206, signal 6, core limit 0
ERROR: apport (pid 30913) Tue Oct 23 12:38:49 2018: executable: /usr/lib/jvm/java-8-oracle/bin/java (command line "<JAVA COMMAND AND OPTIONS GO HERE>")
ERROR: apport (pid 30913) Tue Oct 23 12:38:49 2018: is_closing_session(): no DBUS_SESSION_BUS_ADDRESS in environment
ERROR: apport (pid 30913) Tue Oct 23 12:59:30 2018: core dump exceeded 11238 MiB, dropped from /var/crash/_usr_lib_jvm_java-8-oracle_bin_java.0.crash to avoid memory overflow
ERROR: apport (pid 30913) Tue Oct 23 12:59:30 2018: wrote report /var/crash/_usr_lib_jvm_java-8-oracle_bin_java.0.crash

Кажется, что apport довольно непредсказуемо. В дополнение к этому, вопреки тому, что apport говорит, что не использует kernel.core_uses_pid - каждый дамп кучи использует имя _usr_lib_jvm_java-8-oracle_bin_java.0.crash,

1. Есть ли альтернатива apport для захвата дамп кучи Java?
2. Если нет, есть ли способ собрать всю кучу свалок?
3. Наконец, как насчет core_uses_pid? ApportИсточник предполагает, что его следует использовать, но имена файлов говорят о другом.

Если я могу обновить вопрос с какой-либо дополнительной информацией, пожалуйста, не стесняйтесь спрашивать. Спасибо!