javaspecialist Oct 24 2011 at 09:41

Как бороться с паузами java приложения, не трогая GC

2 min

Java*

+20

Comments 29

dixx Oct 24 2011 at 09:47

Эдак мы скоро к старому доброму C вернёмся. *предвкушая*
GC — зло.

vaevictus Dec 8 2011 at 11:48

Обычно на нагруженном проекте (ну не сайты-визитки же, вы на яве пишите) есть программисты разной квалификации. И если синьорам GС действительно может иногда мешать, то джуниорам и даже мидлам — он просто необходим (кто дебажил код с «потерянным» указателем — поймёт)

kekekeks Oct 24 2011 at 10:02

Возможно, вы обзовёте меня еретиком, но не пробовали ли запускать под IKVM? Мне интересно, какова разница в эффективности GC.

UFO just landed and posted this here

kekekeks Oct 24 2011 at 22:32

А причём тут вообще винда?

kekekeks Oct 24 2011 at 22:44

Собсно mono-sgen --llvm /usr/lib/ikvm/ikvm.exe -jar your_jar_file.jar

UFO just landed and posted this here

1nd1go Oct 24 2011 at 11:45

Возможно ламерский вопрос, но все же:

Первым делом, конечно же стоит выяснить есть ли утечки памяти.

Как ищите?

javaspecialist Oct 24 2011 at 12:18

Обычно анализатором памяти.
Снимпешь heap dump, открываешь и смотришь кто держит объекты, которые по логике вашего приложения уже должны быть собранными. Часто всякие лисенеры держат сильные ссылки на объекты, которые вам больше не нужны.
Можно снять два снепшота с большим интервалом и посмотреть на различия между ними. Только при открывании снепшота, выставите галочку почистить мертвые объекты.
Так же в некоторых анализаторов есть фичи по анализу хипа на подозрения утечек памяти.

sergei-grigorev Oct 24 2011 at 12:43

Даже если это совсем просто — напишите пожалуйста пост об этом. Я уверен, это многим было бы интересно. Я к примеру, ни разу сам еще этим не занимался и мне было бы очень интересно это попробовать.

Regis Oct 24 2011 at 16:53

VisualVM: мониторинг, профилировка и диагностика Java-приложений

Fafnir Oct 24 2011 at 12:42

Вот тут описаны несколько инструментов, может пригодится. А вообще это тема для отдельной полноценной статьи, потому как ловить эти утечки сложнее, чем те же deadlocks.

chernish2 Oct 24 2011 at 12:43

А в чём принципиальное отличие от паттерна «Object pool» en.wikipedia.org/wiki/Object_pool_pattern?
Вроде подход одинаковый, просто немного отличная реализация.

javaspecialist Oct 24 2011 at 12:51

Если я правильно понял вопрос, и Вы спрашиваете, почему я не упомянул данный подход, то, он не поможет при размере кэша в несколько гигабайт, так как все ваши объекты будут лежать в одном и том же Heap, наряду с объектами которые будут требовать сборки, так что GC надо будет запускаться и сканить всю свою память, что обернется большими паузами.

chernish2 Oct 24 2011 at 15:13

Насколько я понял из статьи о Java off-heap cache, там должен использоваться механизм своппинга на жесткий диск, который, я полагаю, отрабатывает в некоторых случаях гораздо медленнее сборщика мусора?

javaspecialist Oct 24 2011 at 15:14

Если вам не нужен персистентный кэш и у вас предостаточно оперативной памяти, то никакого своппинга можно не делать.

Zorkus Oct 24 2011 at 19:45

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

Zorkus Oct 24 2011 at 19:51

Я имею в виду — при своме на жесткий диск off-heap memory, там есть гарантия, что только этот буфер будет сброшен на диск, а не часть java-heap вместе с ним?

javaspecialist Oct 24 2011 at 20:51

Я предпочитаю вооще своп выключать на уровне операционной системы.

alist Oct 24 2011 at 16:41

Вообще-то не вижу проблемы с использованием Java array в качестве хранилища памяти. Используем массивы массивов для хранения мультигигабайтных данных. Функции адресации пишутся один раз, а затем работают на ура. С точки зрения GC результирующая структура гораздо проще для обработки, чем обычные объекты: ведь сложность определяется не тем, сколько объект места в памяти занимает, а тем, сколько ссылок есть внутри этого объекта.

Кто-нибудь может объяснить, чем этот подход хуже, чем тот же Unsafe-аллокатор?

javaspecialist Oct 24 2011 at 16:54

1) Надо же тогда будет самому управлять свободной памятью в в этом массиве.
2) При FullGC на стадии compact GC придеться копировать все эти гигабайты.

CheatEx Oct 24 2011 at 16:51

>… замедление работы приложения, так как теперь объекты надо будет сериализовать…
Позвольте, но для записи в off heap память ведь тоже нужно сериализовывать. Или я не верно понимаю?

javaspecialist Oct 24 2011 at 16:57

да, все верно

Zorkus Oct 24 2011 at 19:48

«Если ваш java Heap больше нескольких гигов (в зависимости от требований приложения), то никакие настройки GC вам не помогут. Будь-то CMS, JRocket или даже уже сто лет разрабатываемый G1, ничего вас в этом случае не спасет»

Вот тут хотелось бы побольше конкретики и ссылок на исследования и прочее. Считаем, конечно, что у нас x64 сервер и x64 JVM. Что и где будет падать?

javaspecialist Oct 24 2011 at 20:54

Ничто нигде падать не будет. Просто паузы GC будут занимать значительное время. Ссылки дать не могу. В качестве пруфа сходите как-ниудь на javaone, там каждый раз с этим соглашаются. Мой личный опыт это так же подтверждает.

lukianol Oct 25 2011 at 15:02

пичальки :)

zenant Oct 30 2011 at 08:52

Поддерживаю автора. В общем правильно все написано. Мы боремся с кучей порядка 80-90 Гб в данный момент. Пока приходится разбивать на 3 JVM по 30Гб каждый, что неидельно. И Если приходит FullGC то минут на 15-20 JVM встает. Пробуем сейчас g1 и разговариваем с Azul, но они не дешевые совсем. Также рестартуем сервера раз в 2 недели. Пока держимся.

javaspecialist Oct 30 2011 at 16:38

Вроде на недавно прошедшем JavaOne прямо сказали, что G1 им довести до ума для больших куч так и не удалось. Работает отлично на маленьких хипах, но не более того, так что сильно не обольщайтесь на его счет.

zenant Oct 30 2011 at 16:47

Да мы и не обольщаемся. Потому с азулом и начали разговаривать, но уж больно это геморное дело. Виртуальная машина и их собственный JVM.