|
|
|
Supreme Being
участник
Last Login: 02.02.2008 19:48
Сообщ.: 480,
Visits: 5 178
|
|
| Мое серверное приложение работает с сетью и базой данных. Поэтому паузы естественны. Но как-то случайно заметил, что есть и паузы, вызванные работой gc. Рискнул отказаться от gc, используемого по умолчанию и включил конкурентный gc, который минимизирует паузы. Эффект превзошел все ожидания. Однако, возможно я нашел не лучшее решение. Только вот хлопотное это дело - экспериментировать на "ходячем" пациенте. Его надо перестартовывать, потом наблюдать. Научное исследование. А как вы тюнинг gc делаете?
|
|
|
|
|
Supreme Being
участник
Last Login: 30.03.2008 17:43
Сообщ.: 247,
Visits: 2 370
|
|
| Может немного и не в тему. Но в абсолютно всех случаях, когда мне хотелось оптимизировать коллектор проблему удавалось решить за счет оптимизации собственной программы.
|
|
|
|
|
Supreme Being
участник
Last Login: 02.02.2008 19:48
Сообщ.: 480,
Visits: 5 178
|
|
| Если под оптимизацией программы понимать ликвидацию утечек памяти, то, действительно, надо с этого начинать. Если в программе накапливаются неосвобождаемые обьекты, то никакой gc не спасет. Однако в любой программе есть временные обьекты с разным жизненным циклом. Что тут можно оптимизировать? Поменять gc все же проще. Например, у меня gc, который был по умолчанию, убирал молодые обьекты за 0,008 сек, но несколько раз в день включал FullGC длительностью 30 сек. А конкурентный включается на 0,02 -0,03 сек и таких огромных пауз не делает.
|
|
|
|
|
Supreme Being
участник
Last Login: 30.03.2008 17:43
Сообщ.: 247,
Visits: 2 370
|
|
mselez (16.11.2006)
Однако в любой программе есть временные обьекты с разным жизненным циклом. Что тут можно оптимизировать?
Программы я не видел, поэтому утверждать ничего не могу. Но разве нельзя переделать временные объекты в постоянные? Т.е. создавать некоторое количество объектов заранее и использовать их по мере необходимости (если программа работает постоянно, думаю есть возможность собрать статистику, сколько экземпляров временных объектов требуется для поддержки работы). Создавать же новые объекты - только в крайних случаях, когда кэш иссякает. Правда если временные объекты не допускают изменения состояния (объекты-значения или как там это называется), то действительно делать нечего...
И еще - 30 секунд пару раз в сутки - это разве много? Или идет речь о системе чуть ли не реального времени? Подпихивать сборщик эдак где-то часа в 2 ночи...
Ну и лирическое отступление: а пользователям задержки доставляют неудобство? Помню случай, довольно давно разрабатывал базу данных и один отчет (самый главный! :) ) готовился около 20 минут. Через пару лет работы программы я ужаснулся сему факту и провел коренную оптимизацию (потратил неделю), отчет стал готовится за 30 секунд. А они как включали расчет и уходили на обед, так и делают по сей день (когда приходят через час - все готово)...
|
|
|
|
|
Supreme Being
участник
Last Login: 02.02.2008 19:48
Сообщ.: 480,
Visits: 5 178
|
|
| Согласен с вашими рассуждениями, но в моем случае 30 сек - это заметно. А относительно идеи не плодить без нужды обьекты и использовать пулы - я тоже так рассуждал и делал. Но это противоречит концепции java. Создатели gc настоятельно этого не рекомендуют. Кроме того, полностью избежать создания временных обьектов трудно, если приложение общается с внешним миром - по крайней мере новые стринги создаются. И эти новые обьекты, если на них ссылка хотя бы одна и пусть даже кратковременно была, уже имеют шанс быть не убраны во время "быстрой" уборки. Часть новых обьектов может накапливаться в ожидании "полной" уборки. Поэтому правильнее подобрать коллектор с нужной стратегией, чем программировать на java в стиле C, экономя каждый байт и каждый обьект.
|
|
|
|
|
Supreme Being
участник
Last Login: 30.03.2008 17:43
Сообщ.: 247,
Visits: 2 370
|
|
mselez (16.11.2006)
... Но это противоречит концепции java. Создатели gc настоятельно этого не рекомендуют.
Кроме того, полностью избежать создания временных обьектов трудно...
Это конечно да. Все в конце концов упирается в конкретную реализацию. Просто всегда подозрительно относился к прямому влиянию на коллектор, как к чему-то типа фола последней надежды... Но с другой стороны и круглосуточно работающих сервеных приложений не писал.
|
|
|
|
|
Supreme Being
участник
Last Login: 23.05.2007 20:20
Сообщ.: 662,
Visits: 5 795
|
|
ННП
mselez, ты все правильно сделал. Для этого его -- concurrent gc -- и заимплементили. Из твоего топика не понятно, но я на всякий случай скажу, что существуют два concurrent gc: один -- для эдема, второй -- для остальной кучи. Так вот включаются они поотдельности каждый. Рекомендую включать их оба, так как не могу придумать сценария, когда был бы нужен один, а второй -- нет.
А про сбор статистики по количесву объектов каждого типа, и использование затем пулов. Смысла нету. Можно так делать, тока JVM все равно быстрее обработает содание и удаление в большинстве случаев. Я говорю о программе, в которой учитывались при программировании особености GC. А по-другому писать смысла нету =)
|
|
|
|
|
Supreme Being
участник
Last Login: 02.02.2008 19:48
Сообщ.: 480,
Visits: 5 178
|
|
| Я использую опцию -XX:+UseConcMarkSweepGC. Судя по логу gc он вроде чистит все - сначала мелкими порциями "свежатину" удаляет, а как только память подбирается к максимуму, делает полную уборку. Используемая память резко (иногда в два три шага) падает. Но главное, паузы меньше секунды.
|
|
|
|
 22.11.2006 11:21 |
| | | |