да, увеливая размер хипа мы автоматически увеличиваем размед и eden, вот только нередко видел ситуации с 1.5G под old и 12M под eden, из параметров были только -Xmx1500m. поведение думаю вы себе представляете.
по поводу тормозов при нехватке permgen, то тут уже сама ява машина должна была ругаться усиленно в лог «java.lang.OutOfMemoryError: PermGen space», что уже должно было насторожить.
пост отписал не к тому что вы что-то неправильно делали, а к тому, что помимо permgen бывают различные ситуации, и к каждой проблеме нужно подходить внимательно.
Так же помимо размера permgen иногда помогает -XX:NewRatio который отвечает за молодое поколение
основной принцип работы gc:
заполнился eden? — чистим мертвецов, выживших закидываем в survivor
заполняется survivor? — меняем местами 2 наших слота survivor (с полным работаем, свободный становится активным, пошло заполнение с eden), вышившие в old
заполнился old? — ну тут уже глобал счастье, курите все пока мы разбираемся с мусором (а при большом heap дело нешустрое)
Основное правило явы «живи быстро, умри молодым», в случае недостаточного количества под young не выполняется.
По умолчанию выделяется достаточно низкий уровень, в итоге под нагрузкой eden забивается моментом, survivor тоже оказывается заполненный, а следовательно объект сразу попадает в old.
В итоге имеем ситуацию:
1. eden дёргается сборщиком мусора практически непрерывно, доп нагрузка на проц.
2. данные перетекают сразу в old, хотя уже в следующий момент оказываются мертвы и лишь занимают память, когда же заполниться old, то сборка по нему это уже совсем другая история с нагрузками на проц.
увеличивая размер eden имеем
1. eden заполняется постепеннь, выжившие зачастую влезают в survivor, так как те кто там уже были к этому времени почти все поумирали
2. old заполняется уже намного медленнее, следовательно глобальный сборщик запуститься позже или отработает меньше времени.
хотя слишком усердствовать тоже не надо, так как алгоритмы сборки мусора по old более оптимальны по скорости сборки и под большие объёмы, во всём нужно искать середину.
по поводу тормозов при нехватке permgen, то тут уже сама ява машина должна была ругаться усиленно в лог «java.lang.OutOfMemoryError: PermGen space», что уже должно было насторожить.
пост отписал не к тому что вы что-то неправильно делали, а к тому, что помимо permgen бывают различные ситуации, и к каждой проблеме нужно подходить внимательно.
основной принцип работы gc:
заполнился eden? — чистим мертвецов, выживших закидываем в survivor
заполняется survivor? — меняем местами 2 наших слота survivor (с полным работаем, свободный становится активным, пошло заполнение с eden), вышившие в old
заполнился old? — ну тут уже глобал счастье, курите все пока мы разбираемся с мусором (а при большом heap дело нешустрое)
Основное правило явы «живи быстро, умри молодым», в случае недостаточного количества под young не выполняется.
По умолчанию выделяется достаточно низкий уровень, в итоге под нагрузкой eden забивается моментом, survivor тоже оказывается заполненный, а следовательно объект сразу попадает в old.
В итоге имеем ситуацию:
1. eden дёргается сборщиком мусора практически непрерывно, доп нагрузка на проц.
2. данные перетекают сразу в old, хотя уже в следующий момент оказываются мертвы и лишь занимают память, когда же заполниться old, то сборка по нему это уже совсем другая история с нагрузками на проц.
увеличивая размер eden имеем
1. eden заполняется постепеннь, выжившие зачастую влезают в survivor, так как те кто там уже были к этому времени почти все поумирали
2. old заполняется уже намного медленнее, следовательно глобальный сборщик запуститься позже или отработает меньше времени.
хотя слишком усердствовать тоже не надо, так как алгоритмы сборки мусора по old более оптимальны по скорости сборки и под большие объёмы, во всём нужно искать середину.