Garbage Collection

[Palych]

1GB это не из той оперы...

[valchkou]

за всё надо платить: чем больше памяти, тем больше GC прибираться, тем дольше оно работает, тем дольше всё стоит и ждёт во время цикла уборки.

Вот-вот, при определённых условиях возникает лавинный эффект, и приложение встаёт колом (я это видео на java 6 в сочетании с глюком в jboss vfs)

мужики да вы сначала попробуйте, палыч, какой жава 6, это что вообще?
вот слушает молодежь вас и думает что жава это гавно. и вместо жавы начинает изучать гавно.
времена изменились, теперь и железки другие и GC и сама жава.
все летает и на 1 гиге и на 12 и на 32х, никаких долгих пауз, милисекунды.
Запустите, поиграйтесь, посмотрите статистику, и уверяю вас вы будете приятно удивлены

12Gb хип?? Жава 8 вроде 1гб максимум, не?

maximum heap size
"Smaller of 1/4th of the physical memory or 1GB. Before Java SE 5.0, the default maximum heap size was 64MB. You can override this default using the -Xmx command-line option."
https://docs.oracle.com/javase/8/docs/t ... omics.html" onclick="window.open(this.href);return false;

нет, то что видите по ссылке это дефолтные значения.

[kostik78]

G1 не работает по лимиту памяти как CMS или другие Java GC. Он как раз статистичесикий. Чем дольше Java работает тем стабильнее паузы, конечно если паттерн аллокации памяти не скачет туда сюда рандомно.
По дефолту G1 впринципе работает намного лучше чем CMS который требует тонкого тюнининга. Но G1 тоже требует настройки и у него есть ахилесовы пяты: Final, Weak, Soft and etc references, требует warm period чтобы статистику набрать и баги еще прут только так. Но в целом наш опыт что G1 работает гораздо предсказуемее и стабильнее чем CMS, которому переодически требуется переделывать fine tuning введу изменившегося кода.

[Palych]

времена изменились, теперь и железки другие и GC и сама жава.
все летает и на 1 гиге и на 12 и на 32х, никаких долгих пауз, милисекунды.

Замечательно!
Так сколько будем ставить - 1 гиг, 12 или 32?

[valchkou]

времена изменились, теперь и железки другие и GC и сама жава.
все летает и на 1 гиге и на 12 и на 32х, никаких долгих пауз, милисекунды.

Замечательно!
Так сколько будем ставить - 1 гиг, 12 или 32?

начать лучше с 0.5 а там как пойдет

[Palych]

Но G1 тоже требует настройки и у него есть ахилесовы пяты: ...Weak, Soft and etc references...

IMHO это не слабости коллектора, а свидетельство неправильной концепции:
Сборщик мусора по определению должен удалять объекты, которые не нужны приложению.
А эти недоссылки позволяют приложению использовать объекты, которые пока еще не нужны сборщику мусора.
Их использование подразумевает что сборщик мусора включается только когда памяти становится мало.
А это не всегда эффективно, и неправильно.
Им нужно отдельный сборщик для Weak/Soft and etc references...

[kostik78]

Но G1 тоже требует настройки и у него есть ахилесовы пяты: ...Weak, Soft and etc references...

IMHO это не слабости коллектора, а свидетельство неправильной концепции:
Сборщик мусора по определению должен удалять объекты, которые не нужны приложению.
А эти недоссылки позволяют приложению использовать объекты, которые пока еще не нужны сборщику мусора.
Их использование подразумевает что сборщик мусора включается только когда памяти становится мало.
А это не всегда эффективно, и неправильно.
Им нужно отдельный сборщик для Weak/Soft and etc references...

Проблема сборки мусора выглядит простой только на первый взгляд. Так что имхо прежде чем сетовать изучите предмет детальнее или хотя бы печальный опыт создателей Golang которые тоже как "дартаяны" кричали что JVM GC говно и они шас забабахают супер пупер GC и застряли с этим. Только к версии 1.6 (после фиксанья багов в новой имплементации GC в версии 1.5) что-то получилось более или менее соотвествующее. При этом Golang концептуальнее создает меньше временного мусора чем JVM. То бишь задача для решения должна была быть проще.

[Flash-04]

Всё это теоретизирование, а на практике я работал с двумя enterprise level приложениями которые обрабатывают хренову кучу данных в real-time. То что написано на Java - глючное и прожорливое. То что написано на C++ быстрое и масштабируемое в отличие от. Стоит ли говорить что последнее за несколько лет отобрало большую часть рынка у первого (которое считалось лучшим минимум 5 лет).

[kostik78]

Всё это теоретизирование, а на практике я работал с двумя enterprise level приложениями которые обрабатывают хренову кучу данных в real-time. То что написано на Java - глючное и прожорливое. То что написано на C++ быстрое и масштабируемое в отличие от. Стоит ли говорить что последнее за несколько лет отобрало большую часть рынка у первого (которое считалось лучшим минимум 5 лет).

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

[Мальчик-Одуванчик]

Всё это теоретизирование, а на практике я работал с двумя enterprise level приложениями которые обрабатывают хренову кучу данных в real-time. То что написано на Java - глючное и прожорливое. То что написано на C++ быстрое и масштабируемое в отличие от. Стоит ли говорить что последнее за несколько лет отобрало большую часть рынка у первого (которое считалось лучшим минимум 5 лет).

Но в последнем случае наверняка придется писать собственный аллокатор, а это мало кто сможет соорудить грамотно.
Хотя семантика переноса, введенная в стандарт 11 года позволяет во многих вещах обходиться без активного использования динамической памяти.

[Flash-04]

Хе-хе, я вам говорю о реальном решении которое сейчас топчет конкурентов сапогами

[Мальчик-Одуванчик]

Интересно, а как сборщик мусора виртуальной машины джавы синхронизируется с остальными процессами в многоядерной системе?

[Palych]

G1 не работает по лимиту памяти как CMS или другие Java GC. Он как раз статистичесикий. Чем дольше Java работает тем стабильнее паузы, конечно если паттерн аллокации памяти не скачет туда сюда рандомно.

Кстати, а почему тогда у Сабины пила?
Сабина, признавайся - пила или не пила?

[Palych]

Хе-хе, я вам говорю о реальном решении которое сейчас топчет конкурентов сапогами

Какого рода приложение?

[kostik78]

Интересно, а как сборщик мусора виртуальной машины джавы синхронизируется с остальными процессами в многоядерной системе?

Что именно синхронизирует - в какой области Вас интересует? Java heap состоит из нескольких зон и сам GC имеет несколько различных фаз. Соотвественно разные виды синхронизации Если Вы про world stop phase - то там все просто - JVM все процессы притормаживает в native code пока GC выполняет финальную фазу. Остальные фазы обычно работают параллельно с основным приложенем. В этом memory metadata что нужна GC защищается обычными синхронизационными примитивами. В случае линуха это pthread lock.
Если что спрашивайте конкретнее - я свое время с CMS на мучалсяизучался вплодь до исходников JVM native. С G1 пока только одна более или менее серезьная проблема была - он не учитывает -noclassgc и по этой причине иногда JVM раком встает. Баг в Java 9 пофиксали а в 8 нужно убрать опцию. Хотя она и правда остатки прошлого. Не нужно имхо в G1 этой оптимизации.

[kostik78]

G1 не работает по лимиту памяти как CMS или другие Java GC. Он как раз статистичесикий. Чем дольше Java работает тем стабильнее паузы, конечно если паттерн аллокации памяти не скачет туда сюда рандомно.

Кстати, а почему тогда у Сабины пила?
Сабина, признавайся - пила или не пила?

Пила равномерна потому что аллокация памяти линейная (равномерная пила это как раз что нужно добиваться в серверном Java code) и G1 работает постоянно чтобы meet the target of execution time. Включите статистику и все увидите, что там пила та пила да не такая как в CMS, где основной сборщик мусора тригирился по memory threshold.

[Palych]

там пила та пила да не такая как в CMS, где основной сборщик мусора тригирился по memory threshold.

То есть - высота зубьев пилы не зависит от размера Xmx?

[kostik78]

там пила та пила да не такая как в CMS, где основной сборщик мусора тригирился по memory threshold.

То есть - высота зубьев пилы не зависит от размера Xmx?

Ответ на этот вопрос не совсем прост. Но в целом не зависит. Но в G1 есть ньюанс, он чем то похож на CMS если Вы расcматриваете отдельный регион (eden gen + metadata + old gen), но в отличие от CMS у которого был только один такой регион G1 делит хип на множество таких кубиков. Там на самом деле есть threshold -XX:InitiatingHeapOccupancyPercent=45. Он говорит G1 на начальном этапе как вести себя пока статистика не набрана еще. Например у нас в продакщен первые 24 часа можно увидеть несколько пауз которые привышают XX:MaxGCPauseMillis но по истечении 24 часов 92% пауз будут <=200ms. И раз в 72-80 часов у нас случаются 800ms паузы но из за FinalReferences что известная проблема у G1. Оптимизация по времени привела к тому что он не очень успевает вызывать finalize на SSL sockets. Ну это отдельная история - как я уже сказал - это детали имплементации

[Flash-04]

Какого рода приложение?

Splunk

[Сабина]

12Gb хип?? Жава 8 вроде 1гб максимум, не?

[Сабина]

времена изменились, теперь и железки другие и GC и сама жава.
все летает и на 1 гиге и на 12 и на 32х, никаких долгих пауз, милисекунды.

Замечательно!
Так сколько будем ставить - 1 гиг, 12 или 32?

У нас 16, все замечательно. Но max memory вообще то ставится в зависимости от системы и приложения

[Flash-04]

А 128 Gb не хотите?

История увеличения памяти для одного и того же приложения:
Вначале жила в 1.6Gb (больше на Win32 нельзя было дать). Потом переехало на Linux64 и пошло:
- 8Gb
- 16 Gb
- 32 Gb
- 64 Gb

(подправлено. на сервере 128Gb, но Java отдали только половину, что логично).

[anarchist]

12Gb хип?? Жава 8 вроде 1гб максимум, не?

Давно я не конфигурил Жаву.
Так мы все еще про размер хипа, или про размер физической памяти на сервере? Что то я с трудом себе представляю нахрена хип размером 12гб для Жава приложения.

[Flash-04]

Иногда и больше надо.

[iDesperado]

Какого рода приложение?

Splunk

а где там С++, если эта фигня поверх java и hadoop построена ? там веб админка, что ли на C++ ?