Comments 29
Эдак мы скоро к старому доброму C вернёмся. *предвкушая*
GC — зло.
GC — зло.
Возможно, вы обзовёте меня еретиком, но не пробовали ли запускать под IKVM? Мне интересно, какова разница в эффективности GC.
Возможно ламерский вопрос, но все же:
Как ищите?
Первым делом, конечно же стоит выяснить есть ли утечки памяти.
Как ищите?
Обычно анализатором памяти.
Снимпешь heap dump, открываешь и смотришь кто держит объекты, которые по логике вашего приложения уже должны быть собранными. Часто всякие лисенеры держат сильные ссылки на объекты, которые вам больше не нужны.
Можно снять два снепшота с большим интервалом и посмотреть на различия между ними. Только при открывании снепшота, выставите галочку почистить мертвые объекты.
Так же в некоторых анализаторов есть фичи по анализу хипа на подозрения утечек памяти.
Снимпешь heap dump, открываешь и смотришь кто держит объекты, которые по логике вашего приложения уже должны быть собранными. Часто всякие лисенеры держат сильные ссылки на объекты, которые вам больше не нужны.
Можно снять два снепшота с большим интервалом и посмотреть на различия между ними. Только при открывании снепшота, выставите галочку почистить мертвые объекты.
Так же в некоторых анализаторов есть фичи по анализу хипа на подозрения утечек памяти.
Вот тут описаны несколько инструментов, может пригодится. А вообще это тема для отдельной полноценной статьи, потому как ловить эти утечки сложнее, чем те же deadlocks.
А в чём принципиальное отличие от паттерна «Object pool» en.wikipedia.org/wiki/Object_pool_pattern?
Вроде подход одинаковый, просто немного отличная реализация.
Вроде подход одинаковый, просто немного отличная реализация.
Если я правильно понял вопрос, и Вы спрашиваете, почему я не упомянул данный подход, то, он не поможет при размере кэша в несколько гигабайт, так как все ваши объекты будут лежать в одном и том же Heap, наряду с объектами которые будут требовать сборки, так что GC надо будет запускаться и сканить всю свою память, что обернется большими паузами.
Насколько я понял из статьи о Java off-heap cache, там должен использоваться механизм своппинга на жесткий диск, который, я полагаю, отрабатывает в некоторых случаях гораздо медленнее сборщика мусора?
Вообще-то не вижу проблемы с использованием Java array в качестве хранилища памяти. Используем массивы массивов для хранения мультигигабайтных данных. Функции адресации пишутся один раз, а затем работают на ура. С точки зрения GC результирующая структура гораздо проще для обработки, чем обычные объекты: ведь сложность определяется не тем, сколько объект места в памяти занимает, а тем, сколько ссылок есть внутри этого объекта.
Кто-нибудь может объяснить, чем этот подход хуже, чем тот же Unsafe-аллокатор?
Кто-нибудь может объяснить, чем этот подход хуже, чем тот же Unsafe-аллокатор?
>… замедление работы приложения, так как теперь объекты надо будет сериализовать…
Позвольте, но для записи в off heap память ведь тоже нужно сериализовывать. Или я не верно понимаю?
Позвольте, но для записи в off heap память ведь тоже нужно сериализовывать. Или я не верно понимаю?
«Если ваш java Heap больше нескольких гигов (в зависимости от требований приложения), то никакие настройки GC вам не помогут. Будь-то CMS, JRocket или даже уже сто лет разрабатываемый G1, ничего вас в этом случае не спасет»
Вот тут хотелось бы побольше конкретики и ссылок на исследования и прочее. Считаем, конечно, что у нас x64 сервер и x64 JVM. Что и где будет падать?
Вот тут хотелось бы побольше конкретики и ссылок на исследования и прочее. Считаем, конечно, что у нас x64 сервер и x64 JVM. Что и где будет падать?
пичальки :)
Поддерживаю автора. В общем правильно все написано. Мы боремся с кучей порядка 80-90 Гб в данный момент. Пока приходится разбивать на 3 JVM по 30Гб каждый, что неидельно. И Если приходит FullGC то минут на 15-20 JVM встает. Пробуем сейчас g1 и разговариваем с Azul, но они не дешевые совсем. Также рестартуем сервера раз в 2 недели. Пока держимся.
Sign up to leave a comment.
Как бороться с паузами java приложения, не трогая GC