здоровые показатели сбора мусора?

Question

я профилировал пакетный импортер jdbc / hibernate. он принимает CSV-преобразование его и импортирует его в базу данных на локальном хосте.

К моему удивлению, операция была связана не с вводом / выводом, а с процессором.

в соответствии с jmx / jconsole и профилировщиком netbeans, похоже, что 60% времени процессора было потрачено в сборщике мусора "старого поколения" остальное используется для геометрических преобразований (это разумно) и управления сеансом гибернации.

другие приложения использовали около 5-10% в соответствии с jconsole так, каковы "типичные" соотношения для процессора / молодого GC / старого GC для таких задач пакетной вставки?

Answer 1

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

Answer 2

после второго взгляда на профилировщик / обходчик кучи netbeans выяснилось, что существует множество экземпляров String, содержащих полные операторы SQL это было вызвано log4jdbc. так что Чарли Мартинс догадался, что это частично верно.

log4jdbc не был настроен для входа в систему любому приложению, но для его уровня журнала все еще было задано значение INFO. хотя файл журнала не содержал никакой информации sql, он все равно отображался в фоновом режиме.

увеличение производительности из-за отсутствия log4jdbc было МАССИВНЫМ.

загрузка ЦП% базы данных увеличилась с 1-2% до 20-50% (одно ядро ​​полностью использовано) ранее 5000 записей были вставлены в пакетном режиме, что заняло около 100 секунд без регистрации один раз блок из 5000 записей теперь вставляется в 1-2 секунды.

GC теперь занимает около 6-7% от общего времени процессора, как и должно быть.

Итак, мой вывод:

Наличие времени GC> 20% является четким признаком того, что что-то не так.

Answer 3

Шестьдесят процентов очень высоко. Это часто указывает на то, что кто-то использует много временных строк или что-то подобное. Тот факт, что это происходит в «старом поколении», предполагает, что это может происходить в конце базы данных, возможно, в ожидании транзакций базы данных. Но это всего лишь конная догадка.

Вы, вероятно, хотите сделать более подробные профили прогона.

Answer 4

Я согласен, что до 10% обычно хорошо для времени GC. Если у вас проблема со старым поколением, попробуйте добавить параметр - XX: NewSize = 300m, где вы можете увеличить молодое поколение. Это помогает избежать больших куч использованных объектов (мусора) в старой области. Особенно, когда у вас просто много локальных объектов, и вы ничего не сохраняете намеренно дольше.