HettЕсть специфичное приложение на яве, если в кратце - это http прокси.
Запущен с параметрами xms=2g, xmx=8g
Почему черзе некоторое время работы хип раздувается до этих 8 гигов? Почему gc раньше мусор не подчищает?

Можно посмотреть параметры "раздувания" / "сжатия" heap'а - по дефолту они достаточно агрессивные. Т.е. что бы Java отдавала память ОС, должно случится практически чудо. приложения фактически всю память должно освободить.
(если правильно помню, настройки при 70% занятой - раздувать и при < 30% - пытаться отдавать)

HettПочему gc раньше мусор не подчищает?

GC мусор то подчищать будет. Но даже в этом случае JVM память ОС может не отдавать (см выше)

Спросите у любого менеджера проекта - если какие-то ресурсы выделены, их нужно беречь и не в коем случае не отдавать обратно ))) Основы менеджмента )))

Hett xms=2g, xmx=8g
Если это реальный enterprise сервер, то передавать память туда-сюда-обратно-тебе-и-мне-приятно ( C ) мурзилка, не очень правильная стратегия

Выделить память сколько требуется всем службам и зафиксировать xms==xmx, в оптимале и своп даже можно выключить (но AFAIK лучше оставить, на случай чрезвычайных ситуаций, а то иногда даже и к консоле не подконектится)

Я бы еще дополнительно ручками бы зафиксировал young / old. Как разработчки, всякие automatic memory management не люблю. Т.к. я лучше знаю, какие требования к памяти моего приложения и самодеятельность JVM даром не нужна.

Если на сервере не хватает памяти для всех работающих служб - значит нужно upgrade'ить сервер.

HettПочему gc раньше мусор не подчищает?
Для инкрементного GC можно задать чистку мусора в фоне, просто по таймеру. Но инкрементный GC не выполняет дефрагментацию памяти, т.ч. смена GC и решение насколько осмысленно/можно на него переходить - требует тестирование (нагрузочного) приложения.

Да и вообще, инкрементным GC решают другую проблему (остановка приложения во время fullGc), Ваше же проблема, крайне надумана. Не выполняется - т.к. памяти достаточно и лишнию работу (запуск GC) делать не нужно.

Хотите, что бы GC запускался чаще - уменьшите память (xms == xmx=...). Хотите, что бы GC запускался режи - увеличьте память. (xms == xmx=...)

IMHO & AFAIK

Hett
Почему "ручной" вызов gc подчищает больше мусора?
Зачем jvm держит лишний мусор, а не удаляет его сразу, как делает это при "ручном" вызове сборщика?

Если вдруг увидел люк, не волнуйся, это глюк ( C )

Ручной вызов от не ручного различаться не должен. Может различаться minorGC и fullGC. Если у Вас fullGC не срабатывает, этому наоборот радоваться нужно.

HettЯ побольше поэкспериментировал, "ручной" вызов освобождает память, но если его вызывать повторно, то он еще освободит, и еще, в итоге из 1.5 гигабайт используемой памяти остается 40 мегабайт.

Если вдруг увидел люк, не волнуйся, это глюк ( C )

1. увеличивается кол-во young чисток, соответственно возрастает возраст объектов в young (servivour) области - они могут начать вычищаться по счетчику возраста жизни. Вроде, по дефолту, объекту разрешается жить от 8 до 32 ротаций eden / servivour.
2. если есть всякие soft / weak reference - нужно читать. как они чистятся
3. если есть объекты выделяемые через JRMI (remote method invocation) - там вообще алгоритмы очистки "взрыв мозга". Даже после полбутылки не разберешься.

Пока ваша проблема надумана. Оно просто так работает.

Не очень понятно, какую проблему решаете. Оптимизируете скорость работы (т.е. что бы full GC запускался реже и паузы / время работы minor GC было быстрее), пытаетесь оптимизировать потребление памяти.

Я бы рекомендовал:
1. Смотреть по логу, а не про графикам
2. Ключивые показатели, IMHO & AFAIK:
2.1. частота запуска, время между запусками minor GC - оно не должно быть очень коротиким. В целом, одна "транзакция" работы HTTP-сервера должна быть быстрее, чем время между запусками minor GC, что бы "временные объекты" случайно не стали "постоянными"
- чем больше young, тем реже запускаемся. Память нужно увеличивать
2.2. время работы minor GC, т.е. пауза на сколько служба будет "стоять колом" при работе minor GC. Чем больше young область, тем время работы minor GC больше (что логично) - т.е. тут young память лучше уменьшать
2.3. кол-во объектов которые после запуска minor GC переносятся в old Gen. В оптимале, т.к. в HTTP-сервере большенство объектов живет только на время запроса, то если время между запусками minor GC достаточно большое. то должно стремится к 0
- увеличиваем young, можно поиграться eden / servivour но обычно это мертвому припарка.
2.4. кол-во памяти остающиеся после чистки full GC - в Вашем случае, занятая область это долгоживущий "кэш" Вашего приложения. Очищаемый размер - кол-во временных объектов просочивщихся в old Gem. Свободная память - она и есть свободная
2.5. частота запуска, время между запусками full GC - в оптимале, может быть вообще 1-2 раза в рабочий день. Сам настраивал enterprise биллинг (Oracle CC&B), изначально full GC работал раз в 15-30 сек, после ручного указания young / old, стал работать 1-2 раза за рабочий день. То, что у Вас full GC не запускается, это и хорошо ! так и надо )))

IMHO & AFAIK

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

Тут только одно ограничение для творчества: young всегда должно быть меньше oldGen. Т.к. AFAIK для HTTP-сервера, оптимально young задирать по максимому (young = oldGen или young = 1/2 oldGen), то можно получить не уменьшаемую/не используемую память в oldGen.

IMHO & AFAIK

p.s.
Теоретически есть automatic параметры, которые сами automatic распределение памяти в JVM могут делать исходя из нужных требований latency / throughinput, но я всегда только руками выставлял.

Поиск в гугле по теме:

Does GC release back memory to OS?
https://stackoverflow.com/questions/30458195/does-gc-release-back-memory-to-os


HettавторВыделить память сколько требуется всем службам и зафиксировать xms==xmx, в оптимале и своп даже можно выключить (но AFAIK лучше оставить, на случай чрезвычайных ситуаций, а то иногда даже и к консоле не подконектится)
На самом деле меня интересовал вопрос, не вывалится ли софт в OME, пока я буду спать. В общем-то научился пользоваться visual jvm, теперь я спокоен.
Подозреваю, у Вас по графику вообще full GC не срабатывает. Т.е. памяти - дофига и больше )))

Тут скорее вопрос ее уменьшения, что бы лишние ресурсы сервера на себя не перетягивать и что бы в OS process killer не запустился, когда все службы распухнут до максимума ))).

p.s.
ну не люблю я xms < xmx. Есть память - выдайте приложениям, нет памяти - тут уже нужно начальство подключать, а не "перестраховываться" выставляя с запасом xmx. IMHO & AFAIK

p.p.s.
если на сервере много Java служб и много процессоров, крайне рекомендую руками выставлять кол-во слежубных thread'ов в JVM (чистка муссора, JIT компилятор, 2-4 потока вполне достаточно). Специфика работы JVM, оптимизация по дефолту: 1 сервер == 1 серверный enterprise процесс JVM, если на сервере 1 сервер == 100500 маленьких JVM'ок, то требуется руками аппетиты JVM урезать.

mayton....Сенсации с новыми Gc которые без пауз я бы поставил под сомнение.
инкрементный GC минимум с 1.6

Но там документированный недостаток, он память не дефрагментирует. Насколько это критично для реальных задач - х.з. Но без нагрузочного тестирования я бы GC не менял.

Если работает - ничего не трогай )))