Комментарии 11
НЛО прилетело и опубликовало эту надпись здесь
Ну, там ничего военного нет. С точки зрения Dalvik VM Замариновский GC — это просто аллокатор. Когда освобождается хендл из C++-кода к Java-объекту, dalvik знает, что теперь объект можно удалить. В то же время внутри Замарина решение о том, что пора освобождать хендл, принимает тамошний GC.
Похожая ситуация бывает в других подобных проектах. Например, Edge.js объединяет .NET и Node.js. Запускается Node-процесс, внутри которого, напомню, крутиться виртуальная машина v8 со своим сборщиком мусора. Edge-модуль внутри этого процесса подгружает DLLи CLR (виртуальной машины .NET), которая в свою очередь также имеет свой сборщик. Поскольку процесс один, то и адресное пространство тоже общее. Но на практике большая часть объектов видна либо для v8, либо для CLR. Два сборщика мусора могут проверять свои участки памяти и чистить ее. А задача Edge как раз и состоит в управлении общими ресурсами и обмена данными между ними.
Похожая ситуация бывает в других подобных проектах. Например, 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 выставляют одинаковыми не просто так, а чтобы не словить паузу во время увеличения хипа.
учитывая тенденцию к уменьшению стоимости физической памяти
Больше хип — больше пауза во время Full GC. При выходе же за 32 гигабайта и отказа от сжатых указателей можно, вообще, оказаться в ситуации менее выигрышной, чем с 30 гигабайтами хипа. Иногда выгодней разбить приложение на несколько JVM, чтобы уменьшить Latency.
Еще можно добавить, что Xms и Xmx выставляют одинаковыми не просто так, а чтобы не словить паузу во время увеличения хипа.
Чем больше памяти выделено приложению, тем лучше работает сборка мусора и тем лучше достигаются количественные характеристики по пропускной способности и времени отклика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.
что то у меня приведенная табличка вызывает подозрения. Особенно сравнение 8гигов именно с 40гигами а не с 31 гигом например. Ведь известно ж что джава включает compressedoops если выставлен хип до 32гигов что и нагрузку на цпу уменьшает и размеры утилизации хипа потому и перформанс на 40гигах хуже изза того что указатели становятся 64битными. Так что в табличке не договаривают кое чего. Не из за большого хипа производительность падает а из-за чрезмерно большого
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Основные принципы настройки Garbage Collection с нуля