Сводка по устранению неполадок памяти JAVA вне кучи

JVM Linux

timg.jpeg

Введение

JVMТрудно устранять неполадки с памятью вне кучи, но проблемы возникают часто Это может быть наиболее полной идеей устранения неполадок с памятью вне кучи JVM.

Благодаря этой статье вы должны знать:

  • команда pmap
  • команда gdb
  • производительная команда
  • Разница между памятью RSS и VSZ
  • java NMT

причина

За последние несколько дней я столкнулся с довольно странной проблемой и почувствовал необходимость поделиться ею с вами. Один из наших сервисов, работающий наdocker, после определенной версии начинает расти занимаемая память доdockerВерхний предел выделенной памяти, но не будетOOM. Изменения версии следующие:

  • Обновлена ​​версия базового ПО
  • Увеличьте лимит памяти докера с 4 ГБ до 8 ГБ.
  • Изменением в последней версии стало использование кэша кучи EhCache.
  • Нет чтения файла и нет операции mmap

использоватьjpsГлядя на параметры запуска, я обнаружил, что было выделено около 3 ГБ памяти кучи

[root]$ jps -v
75 Bootstrap -Xmx3000m -Xms3000m  -verbose:gc -Xloggc:/home/logs/gc.log -XX:CMSInitiatingOccupancyFraction=80 -XX:+UseCMSCompactAtFullCollection -XX:MaxTenuringThreshold=10 -XX:MaxPermSize=128M -XX:SurvivorRatio=3 -XX:NewRatio=2 -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+UseParNewGC -XX:+UseConcMarkSweepGC

Используйте ps для просмотра памяти и виртуальной памяти, используемой процессом (Linux Memory Management). В дополнение к виртуальной памяти относительно высока до17GBКроме того, фактическая используемая память RSS также преувеличена до 7 ГБ, что намного больше, чем-Xmxнастройки.

[root]$ ps -p 75 -o rss,vsz  

RSS    VSZ 7152568 17485844

Процесс устранения неполадок

Очевидно, что использование памяти вне кучи маловероятно из-заEhCacheПричина (потому что мы использовали метод кучи). Понятно, что обновление базового программного обеспечения включает в себя обновление версии netty, и netty будет использовать некоторыеDirectByteBuffer, первый раунд исследования мы используем следующие методы:

  • jmap -dump:format=b,file=75.dump 75Найден путем анализа кучи памятиDirectByteBufferссылка и размер
  • Разверните версию перед обновлением базового программного обеспечения и постоянно наблюдайте
  • Разверните другую версию, измените EhCache, ограничив его размер до 1024 МБ.
  • Учитывая, что это может быть вызвано механизмом выделения памяти Docker, разверните экземпляр на физической машине.

В результате все без исключения службы в четырех средах столкнулись с проблемами чрезмерного использования памяти. Проблема странная, ребенок не может спать.

pmap

Для дальнейшего анализа проблемы мы используем pmap для просмотра распределения памяти процесса, отсортированного в порядке возрастания по RSS. Оказывается, помимо адреса000000073c800000В дополнение к куче 3 ГБ, выделенной выше, существует большое количество сегментов памяти по 64 МБ, и огромное количество небольших блоков физической памяти отображается на разные сегменты виртуальной памяти. Но до сих пор мы не знаем, что внутри и каким образом.

[root]$ pmap -x 75  | sort -n -k3

.....省略N行

0000000040626000   55488   55484   55484 rwx--    [ anon ]

00007fa07c000000   65536   55820   55820 rwx--    [ anon ]

00007fa044000000   65536   55896   55896 rwx--    [ anon ]

00007fa0c0000000   65536   56304   56304 rwx--    [ anon ]

00007f9db8000000   65536   56360   56360 rwx--    [ anon ]

00007fa0b8000000   65536   56836   56836 rwx--    [ anon ]

00007fa084000000   65536   57916   57916 rwx--    [ anon ]

00007f9ec4000000   65532   59752   59752 rwx--    [ anon ]

00007fa008000000   65536   60012   60012 rwx--    [ anon ]

00007f9e58000000   65536   61608   61608 rwx--    [ anon ]

00007f9f18000000   65532   61732   61732 rwx--    [ anon ]

00007fa018000000   65532   61928   61928 rwx--    [ anon ]

00007fa088000000   65536   62336   62336 rwx--    [ anon ]

00007fa020000000   65536   62428   62428 rwx--    [ anon ]

00007f9e44000000   65536   64352   64352 rwx--    [ anon ]

00007f9ec0000000   65528   64928   64928 rwx--    [ anon ]

00007fa050000000   65532   65424   65424 rwx--    [ anon ]

00007f9e08000000   65512   65472   65472 rwx--    [ anon ]

00007f9de0000000   65524   65512   65512 rwx--    [ anon ]

00007f9dec000000   65532   65532   65532 rwx--    [ anon ]

00007f9dac000000   65536   65536   65536 rwx--    [ anon ]

00007f9dc8000000   65536   65536   65536 rwx--    [ anon ]

00007f9e30000000   65536   65536   65536 rwx--    [ anon ]

00007f9eb4000000   65536   65536   65536 rwx--    [ anon ]

00007fa030000000   65536   65536   65536 rwx--    [ anon ]

00007fa0b0000000   65536   65536   65536 rwx--    [ anon ]

000000073c800000 3119140 2488596 2487228 rwx--    [ anon ]

total kB        17629516 7384476 7377520

Через google нашел следующую информацию Linux glibc >= 2.10 (RHEL 6) malloc может показывать чрезмерное использование виртуальной памяти)

В статье указывалось, что причина, по которой приложение подавало заявку на большое количество блоков памяти размером 64 МБ, была вызвана обновлением версии Glibc.export MALLOC_ARENA_MAX=4Это может решить проблему высокой занятости ВСЗ. Хотя это тоже проблема, это не то, что нам нужно, потому что мы увеличиваем физическую память, а не виртуальную память.

NMT

К счастью, в JDK1.8 естьNative Memory Trackerмогу помочь с позиционированием. Добавляя параметры запуска-XX:NativeMemoryTracking=detailможно включить. Выполните jcmd в командной строке, чтобы просмотреть распределение памяти.

#jcmd 75 VM.native_memory summary

Native Memory Tracking: Total: reserved=5074027KB, committed=3798707KB -                 Java Heap (reserved=3072000KB, committed=3072000KB)                            (mmap: reserved=3072000KB, committed=3072000KB) -                     Class (reserved=1075949KB, committed=28973KB)                            (classes #4819)                            (malloc=749KB #13158)                            (mmap: reserved=1075200KB, committed=28224KB) -                    Thread (reserved=484222KB, committed=484222KB)                            (thread #470)                            (stack: reserved=482132KB, committed=482132KB)                            (malloc=1541KB #2371)                            (arena=550KB #938) -                      Code (reserved=253414KB, committed=25070KB)                            (malloc=3814KB #5593)                            (mmap: reserved=249600KB, committed=21256KB) -                        GC (reserved=64102KB, committed=64102KB)                            (malloc=54094KB #255)                            (mmap: reserved=10008KB, committed=10008KB) -                  Compiler (reserved=542KB, committed=542KB)                            (malloc=411KB #543)                            (arena=131KB #3) -                  Internal (reserved=50582KB, committed=50582KB)                            (malloc=50550KB #13713)                            (mmap: reserved=32KB, committed=32KB) -                    Symbol (reserved=6384KB, committed=6384KB)                            (malloc=4266KB #31727)                            (arena=2118KB #1) -    Native Memory Tracking (reserved=1325KB, committed=1325KB)                            (malloc=208KB #3083)                            (tracking overhead=1117KB) -               Arena Chunk (reserved=231KB, committed=231KB)                            (malloc=231KB) -                   Unknown (reserved=65276KB, committed=65276KB)                            (mmap: reserved=65276KB, committed=65276KB)

Хотя адрес памяти, полученный с помощью pmap иNMTВ целом правильно, но там еще много загадок, куда уходит память. Хотя это хороший инструмент, проблема не решена.

gdb

Мне очень любопытно, что находится в 64М или других небольших блоках памяти, а затем передатьgdbсбросить из. читать/procФайл карт в каталоге может точно знать распределение памяти текущего процесса.

Следующий сценарий может сбросить всю связанную память в файл, передав идентификатор процесса (это повлияет на службу, используйте его с осторожностью).

grep rw-p /proc/$1/maps | sed -n 's/^\([0-9a-f]*\)-\([0-9a-f]*\) .*$/\1 \2/p' | while read start stop; do gdb --batch --pid $1 -ex "dump memory $1-$start-$stop.dump 0x$start 0x$stop"; done

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

gdb --batch --pid 75 -ex "dump memory a.dump 0x7f2bceda1000 0x7f2bcef2b000

[root]$ du -h *
dump 4.0K
55-00600000-00601000.dump 400K
55-00eb7000-00f1b000.dump 0
55-704800000-7c0352000.dump 47M
55-7f2840000000-7f2842eb8000.dump 53M
55-7f2848000000-7f284b467000.dump 64M
55-7f284c000000-7f284fffa000.dump 64M
55-7f2854000000-7f2857fff000.dump 64M
55-7f285c000000-7f2860000000.dump 64M
55-7f2864000000-7f2867ffd000.dump 1016K
55-7f286a024000-7f286a122000.dump 1016K
55-7f286a62a000-7f286a728000.dump 1016K
55-7f286d559000-7f286d657000.dump

Время посмотреть, что внутри

[root]$ view 55-7f284c000000-7f284fffa000.dump
^@^@X+^?^@^@^@^@^@d(^?^@^@^@ ÿ^C^@^@^@^@^@ ÿ^C^@^@^@^@^@^@^@^@^@^@^@^@±<97>p^C^@^@^@^@ 8^^Z+^?^@^@ ^@^@d(^?^@^@ 8^^Z+^?^@^@ ^@^@d(^?^@^@
achine":524993642,"timeSecond":1460272569,"inc":2145712868,"new":false},"device":{"client":"android","uid":"xxxxx","version":881},"
device_android":{"BootSerialno":"xxxxx","CpuInfo":"0-7","MacInfo":"2c:5b:b8:b0:d5:10","RAMSize":"4027212","SdcardInfo":"xxxx","Serialno":"xxxx",
"android_id":"488aedba19097476","buildnumber":"KTU84P/1416486236","device_ip":"0.0.0.0","mac":"2c:5b:b8:b0:d5:10","market_source":"12","model":"OPPO ...more

Нани? Разве это содержимое не должно быть в куче? Почему для выделения используется дополнительная память? Причина, по которой netty применяется для прямой буферизации, была проверена выше, так где еще выделяется память вне кучи?

perf

Традиционные инструменты вышли из строя, а навыки исчерпаны, пора довести артефакт до совершенства.

использоватьperf record -g -p 55Включите мониторинг вызовов функций стека. Поработав некоторое время, Ctrl+C завершит работу, и будет сгенерирован файл perf.data.

воплощать в жизньperf report -i perf.dataПросмотрите отчет.

1.jpeg

Как показано на рисунке, процесс выполняет большое количество функций, связанных с bzip. Поиск zip дает следующие результаты:

2.jpeg

-.-!

Процесс вызывает Java_java_util_zip_Inflater_inflatBytes() для обращения к памяти, и лишь небольшая часть вызывает Deflater для освобождения памяти. По сравнению с адресом памяти pmap, bzip действительно делает свое дело.

решать

Проект Java ищет zip, чтобы найти код, и обнаруживает, что действительно существуют связанные операции сжатия и распаковки bzip, иGZIPInputStreamЕсть место, где нет рядом.

GZIPInputStream использует Inflater для обращения к памяти вне кучи, Deflater освобождает память и вызывает метод close() для ее активного освобождения. Если вы забудете закрыть, жизнь объекта Inflater продолжится до следующего GC. Во время этого процесса память вне кучи будет продолжать расти.

Оригинальный код:

public byte[] decompress ( byte[] input) throws IOException {
                ByteArrayOutputStream out = new ByteArrayOutputStream();
                IOUtils.copy(new GZIPInputStream(new ByteArrayInputStream(input)), out);
                return out.toByteArray();
            }

После модификации:

 public byte[] decompress(byte[] input) throws IOException {
        ByteArrayOutputStream out = new ByteArrayOutputStream();
        GZIPInputStream gzip = new GZIPInputStream(new ByteArrayInputStream(input));
        IOUtils.copy(gzip, out);
        gzip.close();
        return out.toByteArray();
    }

После наблюдения проблема решена.

Категории