Что означает раздел «Компилятор» в выходных данных jcmd VM.direct_memory Java и что это может означать, если это будет 4 ГБ - PullRequest
0 голосов
/ 08 мая 2020

У меня есть система на основе JVM, работающая в производственной среде CentOS 7.6 с использованием OpenJDK 11.0.4. Эта система работает хорошо, за исключением того, что JVM использует 4 ГБ прямой памяти «компилятора».

После запуска и прогрева процесса я могу запустить:

jcmd <pid> VM.direct_memory baseline

затем 24 через несколько часов запустите:

jcmd <pid> VM.direct_memory summary.diff

и получите следующий результат:

-                  Compiler (reserved=4195494KB +4194383KB, committed=4195494KB +4194383KB)
                            (malloc=1104KB +100KB #1108 -404)
                            (arena=4194391KB +4194283 #5)
...
-               Arena Chunk (reserved=18014398505287869KB -4194304KB, committed=18014398505287869KB -4194304KB)
                            (malloc=18014398505287869KB -4194304KB)

обратите внимание, что Arena Chunk не работает - базовый уровень показывает гораздо более разумное:

-               Arena Chunk (reserved=4157KB, committed=4157KB)
                            (malloc=4157KB)

Поскольку мне не удалось воспроизвести эту причудливую проблему в наших тестовых средах, я не знаю, с чего начать. Я мог бы использовать несколько указателей. А именно:

  1. Что такое память "компилятора" JVM? Что это означает.
  2. В чем разница между памятью «mallo c» и «арена»?
  3. Любые предложения о том, где искать эту утечку памяти (кроме «попробуйте более новая JVM "). Мы используем luaj (https://github.com/luaj/luaj), поэтому моя первоначальная мысль могла быть странной, но мы не смогли воспроизвести аналогичный профиль памяти при тестировании.
...