Узкое место Java GC Threading на практике?

Question

Насколько хорошо оптимизирован параллельный сборщик мусора Java для многопоточных сред?Я написал многопоточный код Jython, который большую часть времени тратит на вызовы библиотек Java.В зависимости от того, с какими опциями я запускаю программу, библиотечные вызовы либо делают тонны выделений, либо практически ничего.Когда я использую опции, которые требуют тонны выделения кучи, я не могу заставить код масштабироваться до 6 ядер.Когда я использую опции, которые не требуют большого количества выделений, он масштабируется как минимум до 20. Насколько вероятно, что это связано с узким местом GC, учитывая, что я использую стандартную виртуальную машину Sun, параллельные GC и Jythonкак мой клейкий язык?

Редактировать: Просто для пояснения, я не обязательно буду думать о вещах, которые очевидны для ветеранов Java, потому что я почти никогда не использую языки Java / JVM.Я делаю большую часть своего программирования на D и флагманской реализации Python на CPython.Я использую JVM и Jython для небольшого одноразового проекта, потому что мне нужен доступ к библиотеке Java.

Answer 1

Поскольку ваш вопрос касается узких мест в GC: вы можете исключить эту возможность, включив ведение журнала GC и проверку журналов - если имеется большое количество событий GC с большими паузами, вы можете подтвердить или опровергнуть эту теорию.(Однако в сценарии, который вы описываете, я бы предположил, что это не проблема GC).

Answer 2

Для меня проблемы с GC и многопоточностью очень реальны. Я не говорю, что JVM плохая, просто проблема сама по себе очень сложна.

В одном из наших проектов у нас было два приложения, работающие в одной JVM (сервер приложений). Подчеркивая их по отдельности, это было хорошо, но когда оба были стрессом вместе, производительность снижалась странным образом. Мы наконец-то разделили приложения. в двух JVM производительность вернулась к норме (конечно, медленнее, чем при использовании только одного приложения, но разумно).

Настройка ГХ чрезвычайно сложна. Вещи могут улучшиться в течение 5 минут, а затем основная коллекция будет заблокирована и т. Д. Вы можете решить, хотите ли вы высокую производительность или низкую задержку в операциях. Высокая пропускная способность хороша для пакетной обработки, низкая задержка необходима для интерактивного приложения. В конечном счете, параметры JVM по умолчанию были для нас теми, которые дают лучшие результаты!

Это не совсем ответ, скорее возвращение опыта, но да, для меня GC и многопоточность может быть проблемой.

Answer 3

Java GC является поколением. Коллекция первого поколения предназначена для ухода за недолговечными объектами и должна часто запускаться. Работа в течение короткого интервала несколько раз в секунду является ожидаемым поведением, если имеется много кратковременных распределений. (Это должен быть комментарий, а не ответ - у меня нет представителя, извините).

Кроме того, в зависимости от того, какую виртуальную машину вы используете, вы можете выбирать между алгоритмами GC. Параметры будут различаться в зависимости от того, какую версию и поставщика виртуальной машины вы используете.

Некоторая (старая) информация находится здесь: http://java.sun.com/developer/technicalArticles/Programming/turbo/#The_new_GC

Answer 4

Производительность потоков может варьироваться от одной версии JDK к другой.По моему опыту, на jdk6u18 параллельный gc, включенный с -XX: + UseParallelGC ( not одновременная очистка меток gc), очень хорошо работает на четырехъядерном ядре с сотнями очень активных потоков.Я считаю очень маловероятным, что он не будет масштабироваться за пределы 6 ядер.

Тот факт, что аппаратное обеспечение Sun основано на процессорах с большим количеством ядер, объясняет, почему они приложили много усилий для новых сборщиков мусора впоследние годы.

Параллельный gc не включен по умолчанию, поскольку его однопоточная производительность не так хороша, как у gc по умолчанию.