Во-первых, вам нужно знать, что GC может сделать с вашей программой. В зависимости от типа сборщиков, которые вы используете для постоянных и старых поколений, содержимое журналов GC может различаться. Но в целом базовый вывод, который нам нужно получить из журналов сборщика мусора, в основном сосредоточен на следующем:
- Сколько времени занимают второстепенные коллекции?
- Сколько времени занимают основные коллекции?
- Какова частота второстепенных коллекций?
- Какова частота крупных коллекций?
- Сколько восстанавливает незначительная коллекция?
- Сколько восстанавливает крупная коллекция?
- Комбинации вышеперечисленного
Большинство программ имеют очень частые второстепенные коллекции, которые занимают около 90-95% кучи, а остальное передают пространствам Survivor. Последующие коллекции очищают оставшихся в живых примерно на 80% снова, и, по сути, только от 2% до 4% вашей фактической второстепенной коллекции доходят до старого поколения, и циклы этого продолжаются, независимо от того, какой сборщик вы используете.
Теперь проблемы возникают, когда у вас есть сотни второстепенных коллекций небольшого размера на запрос приложения или поток, и при суммировании они занимают значительное время, в основном в секундах с двузначным числом. Так как в современных коллекторах мелкий проход и подметание не останавливают мировые случаи, то это терпимо. Со старым поколением проблемы возникают, когда сборщики бегают, но не забирают ничего крупного. например: обычно сборщик запускается, когда старое поколение заполнено примерно на 80-85%. Это может быть остановкой мирового эпизода, поскольку новые данные не могут быть сохранены в куче, если куча не имеет больше места, что, вероятно, имеет место здесь. Таким образом, потоки приложений приостанавливаются, чтобы позволить потокам сборщика мусора сначала очистить пространство. но как только сборщик завершает работу, коэффициент заполнения кучи не снижается так, как должен. Хороший размер должен уменьшить вашу кучу более чем на 40% за один раз. Если это не так, это означает, что вам нужно больше кучи для сохранения ваших долгоживущих объектов.
Таким образом, по сути, анализ GC - это не «сделать это на основе набора предопределенных шагов». Это скорее HTI и пробный анализ. Это скорее эксперимент, когда вы устанавливаете начальные размеры и настройки, а затем отмечаете или отслеживаете активность GC и записываете результаты. Затем, скажем, после 8-10 прогонов вы сравниваете записи и смотрите, что работает для вашего приложения, а что нет. Это действительно интересная тяжелая работа.
person
Nazgul
schedule
07.12.2014
