Pull to refresh

Comments 11

UFO landed and left these words here
Ну, там ничего военного нет. С точки зрения Dalvik VM Замариновский GC — это просто аллокатор. Когда освобождается хендл из C++-кода к Java-объекту, dalvik знает, что теперь объект можно удалить. В то же время внутри Замарина решение о том, что пора освобождать хендл, принимает тамошний GC.

Похожая ситуация бывает в других подобных проектах. Например, Edge.js объединяет .NET и Node.js. Запускается Node-процесс, внутри которого, напомню, крутиться виртуальная машина v8 со своим сборщиком мусора. Edge-модуль внутри этого процесса подгружает DLLи CLR (виртуальной машины .NET), которая в свою очередь также имеет свой сборщик. Поскольку процесс один, то и адресное пространство тоже общее. Но на практике большая часть объектов видна либо для v8, либо для CLR. Два сборщика мусора могут проверять свои участки памяти и чистить ее. А задача Edge как раз и состоит в управлении общими ресурсами и обмена данными между ними.
Интересные примеры. Было бы полезно тоже самое проделать для java7 и java8.
Я бы еще добавил, что можно дешево снимать информацию с приложения, с помощью Java Mission Control. Правда, «дешево» исключительно в терминах производительности, а не стоимости решения для production. В тестовом же окружении фича бесплатная. Можно записать данные об аллокациях (даже по таймеру) и потом долго «втыкать» за чашечкой кофе.

учитывая тенденцию к уменьшению стоимости физической памяти

Больше хип — больше пауза во время Full GC. При выходе же за 32 гигабайта и отказа от сжатых указателей можно, вообще, оказаться в ситуации менее выигрышной, чем с 30 гигабайтами хипа. Иногда выгодней разбить приложение на несколько JVM, чтобы уменьшить Latency.

Еще можно добавить, что Xms и Xmx выставляют одинаковыми не просто так, а чтобы не словить паузу во время увеличения хипа.
Кроме того, gc.log довольно удобно анализировать с помощью IBM Support Assistant, в продакшене так искали вялотекущие утечки памяти, да и точку, когда что-то начинает пожирать память легко вычислить, а дальше по логам разбираться.
Чем больше памяти выделено приложению, тем лучше работает сборка мусора и тем лучше достигаются количественные характеристики по пропускной способности и времени отклика
WUT? При увеличении памяти можно получить значительное увеличение дисперсии (упрощенно — разброса) latency. При большой куче время полной сборки (full gc) с s-t-w (wtop the world) паузой больше, что означает увеличение latency, если доходит до full gc.

Некоторые товарищи запускают jvm с огромным хипом и периодически просто рестартуют целиком, не дожидаясь full gc.

Из классики. В антипаттернах использования Apache Cassandra есть прекрасная табличка, показывающая к чему может приводить бездумное увеличение -Xms/Xmx.

У нас на одной задаче при -Xmx от 12G до 16G на ноде Кассандры были жуткие тормоза, высокое latency, таймауты и потери insert'ов, при 8G всё стало работать стабильно с нормальным потоком (6 нод по 500-600 MByte/s per node, на 2x SSD в RAID1).

В какой-то теме ранее упоминал этот кейс, но там была неточность. Указанный там поток (50 Mbit/s) относился к входному потоку на нодах, до join'а со словарями в памяти и некоторой денормализации данных из исходного потока.
В Cassandra причина еще и в том, что там активно используется off-heap cache. И чем больше памяти забирает Java, тем меньше памяти остается на дисковый кэш и на этот off heap cache.
У нас была довольно старая cassandra, до появления off-heap row cache (он появился в 1.0, если правильно помню). Кроме того, даже при нем 8G или 16G на машине с 256G с точки зрения кэша — без разницы.
что то у меня приведенная табличка вызывает подозрения. Особенно сравнение 8гигов именно с 40гигами а не с 31 гигом например. Ведь известно ж что джава включает compressedoops если выставлен хип до 32гигов что и нагрузку на цпу уменьшает и размеры утилизации хипа потому и перформанс на 40гигах хуже изза того что указатели становятся 64битными. Так что в табличке не договаривают кое чего. Не из за большого хипа производительность падает а из-за чрезмерно большого

Сразу под табличкой пример из жизни с хипом 12-16G против 8G. И там, и там comperessedoops, ессно.

Под табличкой ваш пример я конечно видел. Может бытб именно вашему примеру есть какое то другое обьяснение. Но я обратил внимание именно на табличку. Что очень умело выбраны размеры хипа для сравнения. Хитро выбраны я бы сказал
Only those users with full accounts are able to leave comments. Log in, please.