Попытка найти утечку! Что означает анон для pmap?

Я пытаюсь найти, где моя память перешла на Java-процесс, запущенный в Linux. Кто-то предложил использовать pmap -x, чтобы точно видеть, что делает память.

Выход действительно длинный, но в основном хорошая его часть повторяется:

00007fbf75f6a000    1016       -       -       - rwx--    [ anon ]
00007fbf76068000      12       -       -       - -----    [ anon ]

Что именно это означает? Почему у меня так много записей этого (4000 +)?

Ответ 1

Блоки Anon представляют собой "большие" блоки, выделенные через malloc или mmap - см. manpages. Таким образом, они не имеют ничего общего с кучей Java (кроме того, что вся куча должна храниться только в таком блоке).

По моему опыту, стеки потоков также используют анонные блоки. Если вы видите много блоков анонов, которые имеют одинаковый размер, а этот размер составляет от 512 до 4 Мб (пример ниже повторяется в течение десятка раз для процесса Tomcat, который у меня работает), это вероятная причина. В зависимости от программы у вас может быть до нескольких десятков из них; если вы видите тысячи, это означает, что у вас есть проблема с потоками.

b089f000    504K rwx--    [ anon ]
b091d000     12K -----    [ anon ]
b0920000    504K rwx--    [ anon ]
b099e000     12K -----    [ anon ]
b09a1000    504K rwx--    [ anon ]
b0a1f000     12K -----    [ anon ]

Но это оставляет вопрос: почему вы используете pmap для диагностики проблемы памяти Java?

Ответ 2

См. эта часть this часть настройки производительности системы для анонимной памяти.

Ответ 3

Использовать Mcl Eclipse (когда вы получаете OutOfMemoryExceptions в куче Java, а не нативную кучу).

Ответ 4

Я видел этот шаблон раньше в потоке. Если у вас есть код, который пытается объединить потоки, но каким-то образом запутывает и течет поток, вы получаете такой же шаблон в pmap.

Я думаю, что каждый бит памяти является минимальным размером стека для потока, конечно, это не имеет ничего общего с кучей в нашем случае.
Мы по-прежнему получаем OutOfMemoryErrors, когда попадаем в пределы ОС, даже если мы анализируем кучу, она не засевается.

Когда у нас возникла такая проблема, pmap [pid] | grep -c 12K оказалось числом используемых потоков.