Как делать оптимизацию коллектора?

Мое серверное приложение работает с сетью и базой данных. Поэтому паузы естественны. Но как-то случайно заметил, что есть и паузы, вызванные работой gc. Рискнул отказаться от gc, используемого по умолчанию и включил конкурентный gc, который минимизирует паузы. Эффект превзошел все ожидания. Однако, возможно я нашел не лучшее решение. Только вот хлопотное это дело - экспериментировать на "ходячем" пациенте. Его надо перестартовывать, потом наблюдать. Научное исследование. А как вы тюнинг gc делаете?

0

Может немного и не в тему. Но в абсолютно всех случаях, когда мне хотелось оптимизировать коллектор проблему удавалось решить за счет оптимизации собственной программы.

0

Если под оптимизацией программы понимать ликвидацию утечек памяти, то, действительно, надо с этого начинать. Если в программе накапливаются неосвобождаемые обьекты, то никакой gc не спасет. Однако в любой программе есть временные обьекты с разным жизненным циклом. Что тут можно оптимизировать?
Поменять gc все же проще. Например, у меня gc, который был по умолчанию, убирал молодые обьекты за 0,008 сек, но несколько раз в день включал FullGC длительностью 30 сек. А конкурентный включается на 0,02 -0,03 сек и таких огромных пауз не делает.

0

mselez (16.11.2006) Однако в любой программе есть временные обьекты с разным жизненным циклом. Что тут можно оптимизировать?

Программы я не видел, поэтому утверждать ничего не могу. Но разве нельзя переделать временные объекты в постоянные? Т.е. создавать некоторое количество объектов заранее и использовать их по мере необходимости (если программа работает постоянно, думаю есть возможность собрать статистику, сколько экземпляров временных объектов требуется для поддержки работы). Создавать же новые объекты - только в крайних случаях, когда кэш иссякает. Правда если временные объекты не допускают изменения состояния (объекты-значения или как там это называется), то действительно делать нечего...

И еще - 30 секунд пару раз в сутки - это разве много? Или идет речь о системе чуть ли не реального времени? Подпихивать сборщик эдак где-то часа в 2 ночи...

Ну и лирическое отступление: а пользователям задержки доставляют неудобство? Помню случай, довольно давно разрабатывал базу данных и один отчет (самый главный! ) готовился около 20 минут. Через пару лет работы программы я ужаснулся сему факту и провел коренную оптимизацию (потратил неделю), отчет стал готовится за 30 секунд. А они как включали расчет и уходили на обед, так и делают по сей день (когда приходят через час - все готово)...

0

Согласен с вашими рассуждениями, но в моем случае 30 сек - это заметно. А относительно идеи не плодить без нужды обьекты и использовать пулы - я тоже так рассуждал и делал. Но это противоречит концепции java. Создатели gc настоятельно этого не рекомендуют.
Кроме того, полностью избежать создания временных обьектов трудно, если приложение общается с внешним миром - по крайней мере новые стринги создаются. И эти новые обьекты, если на них ссылка хотя бы одна и пусть даже кратковременно была, уже имеют шанс быть не убраны во время "быстрой" уборки. Часть новых обьектов может накапливаться в ожидании "полной" уборки. Поэтому правильнее подобрать коллектор с нужной стратегией, чем программировать на java в стиле C, экономя каждый байт и каждый обьект.

0

mselez (16.11.2006) ... Но это противоречит концепции java. Создатели gc настоятельно этого не рекомендуют. Кроме того, полностью избежать создания временных обьектов трудно...

Это конечно да. Все в конце концов упирается в конкретную реализацию. Просто всегда подозрительно относился к прямому влиянию на коллектор, как к чему-то типа фола последней надежды... Но с другой стороны и круглосуточно работающих сервеных приложений не писал.

0

ННП



mselez, ты все правильно сделал. Для этого его -- concurrent gc -- и заимплементили. Из твоего топика не понятно, но я на всякий случай скажу, что существуют два concurrent gc: один -- для эдема, второй -- для остальной кучи. Так вот включаются они поотдельности каждый. Рекомендую включать их оба, так как не могу придумать сценария, когда был бы нужен один, а второй -- нет.



А про сбор статистики по количесву объектов каждого типа, и использование затем пулов. Смысла нету. Можно так делать, тока JVM все равно быстрее обработает содание и удаление в большинстве случаев. Я говорю о программе, в которой учитывались при программировании особености GC. А по-другому писать смысла нету =)

0

Я использую опцию -XX:+UseConcMarkSweepGC. Судя по логу gc он вроде чистит все - сначала мелкими порциями "свежатину" удаляет, а как только память подбирается к максимуму, делает полную уборку. Используемая память резко (иногда в два три шага) падает. Но главное, паузы меньше секунды.

0

Danissimo (21.11.2006) ННП А про сбор статистики по количесву объектов каждого типа, и использование затем пулов. Смысла нету. Можно так делать, тока JVM все равно быстрее обработает содание и удаление в большинстве случаев. Я говорю о программе, в которой учитывались при программировании особености GC. А по-другому писать смысла нету =)

Чисто не там где убирают, а где не сорят

0

Чисто не там где убирают, а где не сорят

Я поставил NetBeans 5.5 , потому что к нему есть дополнительный модуль для профайлинга. Довольно удобная штука - можно в реальном времени понаблюдать за процессами, обьектами и уборкой мусора. Хорошая документация и примеры. Рекомендую.
Как я и ожидал, самый интенсивный мусор - это обьекты char[]. Можно также проследить, кто "сорит". У меня это класс StringBuffer. Явной "утечки" нет. Если обьект в момент прихода коллектора имел ссылку, то его возраст увеличивается на 1 . Поскольку момент прихода коллектора непредсказуем, то явно управлять уборкой обьектов сложно - все равно что-то будет убрано сразу, а что-то потом, т.е. будет накапливаться.
Думаю, что не "сорить" в java - это утопия.

0