А как нынче жабку-то тюнить?

вон 850 МБ жрёт

Для жабы это ничто. Тюнинг полезен в 1% случаев. Лучше свой говнокод перепиши как следует. Пользы больше будет.

Тюнить? 21 век на дворе. Просто прикупи еще этой хрустящей памяти, да не задавай вопрсов.

Говнокод не мой.

Для жабы это ничто

И да, распространители мифов о прожорливости жабы словно не видели Java ME. Жабка очень даже прилично себя ведёт, если ей замок на холодильник повешать, просто меры не знает. Даже электроноподелия так не наглеют и под memory pressure пытаются умерять аппетиты.

Я точно на ЛОР попал или на пейсбук?

Что в permSize и ss прописано? ну и сколько тредов внутри этой шарманки? Но собственно никто не мешает из сишечки дергаемой через jni заалокейтить всю доступную в системе память, ну и еще jit`аный код, байтбуфферы которые могут быть в off-heap.

Не буду создавать отдельную тему, раз тут такая пьянка. Скажите, как дать яве БОЛЬШЕ памяти? В системе 8 гигов, а она даже под сильной нагрузкой жрет не более гига!

Уберите слишком маленькое значение Xmx, которое показано в примере афтара темы, который якобы не читал гайдов (во что я впрочем верю, так как слово «гайд» не существует). По умолчанию будет использовано большее значение. Или можете задать его явно, но в разумных пределах. 64-битная Java позволяет задавать Xmx даже больше объём оперативной памяти, но тогда возможно торможение из-за использования виртуальной памяти. 32-битная Java позволяет задавать Xmx немного более 1 ГБ, но это будет больше, чем значение по умолчанию.

То есть если в системе много памяти, то не факт, что ява ее будет использовать? Я ничего не менял, в томкате все по умолчанию в плане тюнинга.

Экзактли. Более того указав большой xmx не факт что приложению станет лучше. Просто будет реже происходить сборка мусора и в памяти будет болтаться больше старых объектов. Из практических советов - ставь xms и xmx одинакового размера и не увлекайся xmx больше 32гб не имея серьезных на это причин.

permSize

Тред же о ≥8, где пермген выкинули.

ss

Пару мегабайт погоды не сделают.

jit`аный код

Пробовал вчера -Xmaxjitcodesize прикручивать, но оно даже с большими значениями OOM-илось почему-то.

Факт, что не будет вся использоваться без подбора настроек. Для наблюдения над фактическим расходом памяти можно использовать программы jconsole и jvisualvm из состава JDK.

пермген выкинули

вечер, туплю.

запусти с -XX:NativeMemoryTracking=summary
и посмотри что показывает
jcmd {PID} VM.native_memory summary

О, за jconsole спасибо, АТО jmap протух.

michey

Откуда тогда байки, что ява сжирает всю память?

Ну теоретически ты можешь сожрать всю память, даже из жавакода, из-за офхипа,но это
маловероятно.

Нытье взялось из-за того что очень просто наговнокодится до утечек памяти. Собственно на фоне хромого и electron'а нытье про жабку закончилось.

-Xms8g ?

на фоне хромого и electron'а нытье про жабку закончилось

А как нынче жабку-то тюнить? (комментарий)

У мну даже пиджин жрёт поболее некоторых электроноподелок.

Нытье взялось из-за того что очень просто наговнокодится до утечек памяти.

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

Посложнее чем в жс, но самое простое - добавление объектов в static листы, незакрытые IOStream'ы.

Так же, как и в плюсишечке: оставляешь где-то референсы неподчищенные — и оно течёт. Как от этого застрахует GC? никак.

Хотя основная причина «протекания» нынче, пожалуй — налегание на оперативку как на самый доступный способ экстенсивного развития. Впрочем, сейчас вон ещё на дисковый I/O налегать начинают, SSD же типа в каждой кофеварке, и на них даже можно хранить данные без страха потерять их от полугодового оффлайна, да-да!

com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file: target process not responding or HotSpot VM not loaded
	at sun.tools.attach.LinuxVirtualMachine.<init>(LinuxVirtualMachine.java:106)
	at sun.tools.attach.LinuxAttachProvider.attachVirtualMachine(LinuxAttachProvider.java:63)
	at com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:208)
	at sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:147)
	at sun.tools.jcmd.JCmd.main(JCmd.java:131)

Ну не. Говорю же — вылезай из криокамеры; Sun он откопал, фигасе.

target process not responding or HotSpot VM not loaded

λ thinkpad pep → λ git master → java -version                                                                                                                            [1/349]
java version "1.8.0_192"                                                                                                                                                                      
Java(TM) SE Runtime Environment (build 1.8.0_192-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.192-b12, mixed mode)
λ thinkpad pep → λ git master → jcmd 25939 VM.native_memory summary
25939:

Native Memory Tracking:

Total: reserved=1784927KB, committed=502895KB
-                 Java Heap (reserved=262144KB, committed=261120KB)
                            (mmap: reserved=262144KB, committed=261120KB)

-                     Class (reserved=1112028KB, committed=69700KB)
                            (classes #9009)
                            (malloc=10204KB #7493)
                            (mmap: reserved=1101824KB, committed=59496KB)

-                    Thread (reserved=104218KB, committed=104218KB)
                            (thread #102)
                            (stack: reserved=103768KB, committed=103768KB)
                            (malloc=331KB #515)
                            (arena=119KB #199)

-                      Code (reserved=251717KB, committed=13037KB)
                            (malloc=2117KB #3746)
                            (mmap: reserved=249600KB, committed=10920KB)

-                        GC (reserved=19969KB, committed=19969KB)
                            (malloc=10385KB #170)
                            (mmap: reserved=9584KB, committed=9584KB)

-                  Compiler (reserved=270KB, committed=270KB)
                            (malloc=139KB #362)
                            (arena=131KB #7)

-                  Internal (reserved=12834KB, committed=12834KB)
                            (malloc=12802KB #44054)
                            (mmap: reserved=32KB, committed=32KB)

-                    Symbol (reserved=18558KB, committed=18558KB)
                            (malloc=15992KB #133639)
                            (arena=2565KB #1)

-    Native Memory Tracking (reserved=2990KB, committed=2990KB)
                            (malloc=15KB #170)
                            (tracking overhead=2976KB)

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

Память ограничивается через Mx. Ну на служебные расходы чуток уйдёт, но в твоём случае если ты память меряешь правильно, то протекает не управляемая память, или какая-нибудь либа, дёргаемая через JNI или всякие Unsafe-трюки для выделения памяти. Тут жава ничего сделать не может, надо править приложение.

добавление объектов в static листы

В каком месте это утечка, если приложение их использует?

незакрытые IOStream'ы

С приходом try-with-resources не актуально.

Что протекает, то и тюнь. (А как ещё?)

Не понял. В сях ты резервируешь память руками и забываешь про нее, это нормально и так все делают. А в яве ручного управления памятью нет. Забыл референс, закончился скоуп, сборщик мусора придет и заберет его душу.

Не, понятно что классическую утечку - забыл free в java ты не получишь.

С приходом try-with-resources не актуально.

Актуально, актуально. Если ты в try() запихиваешь два Closeable, и закрытие первого кидает эксепшен, то второй не закроется.

это нормально и так все делают

Ніт. Выделять память руками в куче надо лишь в особых случаях. А в плюсах и это зашкварно, если есть возможность завернуть это дело в выделяемый на стеке объект, который по завершению скоупа корректно деструктнется и всё почистит.

Забыл референс, закончился скоуп

Вот только референсы могут гулять по куче классов и где-то случайно осесть, и так стопицот раз. Собсна, со всякими RefPtr та же проблема, но они хоть явные, а тут не.

Так жабка и протекает же, by design. Пока память есть — жрём, закончилась — запускаем GC, GC зафейлился — OOM.

Выкинуть жабу, накать всё на с++/рюст/етц.

Опять читатели по диагонали — мопед не мой. Надо было в /admin/ запостить, пожалуй, чтобы хоть частично таких отсеять.

Не жрет больше памяти, даже если в системе ее много, значит ей это не нужно.

Как ты заметил, что что-то протекает в Java, а не в приложении, с помощью каких инструментов?

Ну давай рассказывай: как жабоприложение может не протекать, если жаба не предоставляет инструментов для явного высвобождения и переиспользования уже ненужной памяти? В коде ведроидоприложений нередко встречается шаманство типа многократного вызова GC, потому что по факту GC даже по требованию не всегда вызывается, кек.

Ты комментариев обчитался? Тред об обратном.

Жабка не будет жрать память если её не будет в системе.

Если у Вас нету тёти — то Вам её не потерять, угу.

Ты собрался тюнить то, о чём понятия не имеешь, так как не пользуешься средствами измерения и/или пользуешься слишком грубыми прикидками, основанными на вере в собственные способности. Как с таким жить? Ну, я бы не стал.

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

уииииии врётииииии в жабке есть free() хип нитичот

Понятно.

Я вот подумал, что пора бы завести (опять) UKSM, он против пустых страниц хорошо справляться должен.

Актуально, актуально. Если ты в try() запихиваешь два Closeable, и закрытие первого кидает эксепшен, то второй не закроется.

Это неправда.