Затмение не освобождает память в процессе Java на Linux

Question

Мой сервер Linux должен иметь возможность обрабатывать более 30 экземпляров затмения для разработчиков.Я сделал быстрый тест запуска 10 экземпляров затмения.Процесс Java, связанный с каждым затмением, первоначально занимал около 200 МБ памяти RSS и увеличивался до 550 МБ при загрузке большего количества проектов.

Но процесс Java, похоже, не освобождает память после закрытия / удаления всех проектов в затменииэкземпляров.Я все еще вижу, что он использует более 550 МБ RSS.

Как я могу изменить настройки Eclipse или Java, чтобы уменьшить объем памяти, когда разработчики закрывали проекты или некоторое время простаивали?

Спасибо

Answer 1

Возможно, вы захотите поэкспериментировать с этими (и другими) параметрами настройки JVM , чтобы сделать JVM менее склонной к возврату памяти в ОС:

-XX: MaxHeapFreeRatio Максимальный процент свободного кучи после ГХ, чтобы избежать сжатия. По умолчанию 70. -XX: MinHeapFreeRatio Минимальный процент свободного кучи после GC, чтобы избежать расширения. По умолчанию 40.

Тем не менее, я подозреваю, что вы не увидите, как процесс eclipse сжимается до уровня, близкого к его первоначальному размеру, поскольку eclipse - это огромное сложное приложение, которое, вероятно, выполняет ленивую загрузку (но не выгружает, если используется) много классов. и связанные структуры данных.

Answer 2

Я никогда не видел релизную память Java.

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

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

Установите -Xmx ниже.

Разделите ваши экземпляры на категории с высоким -Xmx и низким -Xmx и позвольте пользователю определить, какой он хочет.

В качестве побочной мысли, если это действительно имеет для вас значение, вы МОЖЕТЕ иметь возможность запускать несколько экземпляров затмения под одной виртуальной машиной. Вероятно, это было бы СЛИШКОМ много работы (человеко-недель до человеко-лет), но если бы вы могли сделать это правильно, вы могли бы сократить накладные расходы, как 150-200 МБ / экземпляр. Недостатком было бы то, что сбой виртуальной машины (довольно редкий в наши дни) убил бы всех.

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

Answer 3

Переключите Java для использования сборщика мусора G1 с параметрами HeapFreeRatio.Используйте эти параметры в eclipse.ini:

-XX:+UnlockExperimentalVMOptions
-XX:+UseG1GC
-XX:MinHeapFreeRatio=5
-XX:MaxHeapFreeRatio=25

Теперь, когда Eclipse съедает более 1 ГБ ОЗУ для сложной операции и переключается обратно на 300 МБ после сбора мусора, память будет возвращена обратно в операционнуюсистема.

Answer 4

Я бы посоветовал проверить сборку мусора, установить правильные параметры или даже периодически принудительно использовать GC, что может увеличить время, пока использование памяти затмения не вырастет. Следующая ссылка может быть полезной http://www.eclipsezone.com/eclipse/forums/t93757.html