Причины наблюдения высокого “Времени % в GC” в понедельник Перфекта
Если Вы программируете в Java, JDBC является хорошим примером. JDBC определяет ряд интерфейсов, но ничего не говорит о реализации. Ваши приложения могут быть записаны против этого набора интерфейсов. В теории Вы выбираете некоторый драйвер JDBC, и Ваше приложение просто работало бы. Если Вы обнаруживаете, что существует более быстрый или "лучший" или более дешевый драйвер JDBC или по любой причине, Вы можете снова в теории реконфигурировать свой файл свойств, и не имея необходимость вносить любое изменение в Вашем приложении, Ваше приложение все еще работало бы.
2 ответа
Да, это действительно звучит чрезмерно. Уменьшение количества GC, вероятно, было бы единственным лучшим шагом, который вы могли бы предпринять для сокращения времени выполнения вашего приложения (если это ваша цель).
Высокий "% времени в GC" обычно вызван выделением, а затем отбрасыванием тысячи или миллионы объектов. Хороший способ узнать, что происходит, - использовать инструмент профилирования памяти.
Microsoft предоставляет бесплатный CLR Profiler . Это покажет вам каждое выделение, но заставит ваше приложение работать в 10-60 раз медленнее. Возможно, вам придется запустить его с меньшим количеством входных данных, чтобы он мог завершить анализ в разумные сроки.
Отличным коммерческим инструментом является SciTech's .NET Memory Profiler . Это значительно снижает накладные расходы на время выполнения, и доступна бесплатная пробная версия. Делая несколько снимков во время работы вашего процесса, вы можете узнать, какие типы объектов часто выделяются (а затем уничтожаются).
После того, как вы определили источник распределения, вам нужно изучить код и выяснить, как можно сократить эти ассигнования. Хотя не существует универсальных ответов, некоторые вещи, с которыми я сталкивался в прошлом, включают:
- String.Split может создавать сотни небольших короткоживущих строк. Если вы много манипулируете строкой, это может помочь обработать строку, посимвольно перемещаясь по ней.
- Создание массивов или списков тысяч небольших классов (скажем, размером менее 24 байтов) может быть дорогие; если эти классы можно рассматривать как типы значений, это может (иногда) значительно улучшить ситуацию, превратив их в структуры.
- Создание тысяч небольших массивов может значительно увеличить использование памяти (поскольку каждый массив имеет небольшие накладные расходы); иногда они могут быть заменены одним большим массивом и индексируются в его подсекции.
- Наличие большого количества финализируемых объектов (особенно если они не удаляются) может оказать сильное давление на сборщик мусора; убедитесь, что вы правильно удаляете все объекты IDisposable, и обратите внимание, что ваши собственные типы (почти) никогда не должны иметь финализаторов .
- У Microsoft есть статья с Рекомендациями по сборке мусора для улучшения производительность.
Другая причина может заключаться в большом количестве коллекций поколения 1 или поколения 2, каждая из которых занимает НАМНОГО больше времени и вызвана более длительным удержанием объектов.
Я видел, как это происходит в веб-приложениях, когда объекты с ошибками висят на реальных объектах страницы, заставляя страницу существовать столько же, сколько другие объекты, ссылающиеся на них.
Разрыв связи между объектами и страницами (в данном случае) заставлял сборщик мусора упасть на очень низкие значения. Наш сайт теперь имеет более 100 обращений в секунду, а время сборки мусора обычно составляет 1% или меньше.