Когда обращаться к фрагментации управляемой кучи

Question

Я читал в блоге запись Джоша Смита, где он использовал механизм кэширования, чтобы «уменьшить управляемую фрагментацию кучи». Его кэширование уменьшает количество создаваемых объектов с коротким сроком службы за счет немного меньшей скорости выполнения.

Насколько серьезной проблемой является фрагментация управляемой кучи в управляемом языке, таком как C #? Как вы можете диагностировать, если это проблема? В каких ситуациях вам, как правило, нужно решать эту проблему?

Answer 1

Когда

Не слишком быстро. Как правило, иметь недолговечные объекты очень дешево. Чтобы тайник был прибыльным, должно быть (очень) много кандидатов, и они должны прожить достаточно долго, чтобы добраться до следующего поколения.

Как вы можете диагностировать, если это проблема?

с профилировщиком. Я не уверен, что автор статьи сделал это.

Насколько серьезной проблемой является фрагментация управляемой кучи в управляемом языке, таком как C #?

Насколько я знаю, это редко. .NET имеет компактный сборщик мусора, который предотвращает большинство форм фрагментации. Иногда возникают проблемы с кучей больших объектов.

---

Edit:

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

Вывод: Измерьте перед началом оптимизации. Это не была хорошая идея / пример.

Answer 2

Если вы не имеете дело с 10K + небольшими недолговечными объектами в секунду, это не должно быть проблемой на современном компьютере с разумным объемом оперативной памяти.

Итак, сначала вы должны запустить код во всех разумных сценариях, и, если он достаточно быстрый, не беспокойтесь об этом.

Если вас не устраивает скорость, вы видите, что код иногда «задыхается» или просто любопытен, вы можете отслеживать различные характеристики памяти .NET (http://msdn.microsoft.com/en-us/library/x2tyfybc.aspx) в приложении Performance Monitor (входит в состав Windows ). В частности, вы заинтересованы в% времени в GC.

Профилировщик

redgate ANTS также отслеживает эту статистику.

Answer 3

Фрагментация управляемой кучи обычно происходит из-за закрепления объектов. Объекты прикрепляются, когда управляемый код передает указатель объекта на собственный код, и объект не может быть перемещен, поскольку ссылка передается на собственный код. Это очень распространено, когда много операций ввода-вывода. Как упомянуто выше, это обычно происходит только в LOH.

Вот пример Фрагментация в куче Gen0

Answer 4

В отличие от других ответов, приведенных здесь, я заявляю: да, нужно позаботиться о фрагментации! Это относится не только к управляемым кучам, но и ко всем приложениям, обрабатывающим (по крайней мере)

• много "больших" ресурсов в
• шаблон тяжелого распределения.

Поскольку большой объект не уплотняется, он - со временем - наиболее вероятно будет фрагментирован, как только размер и количество объектов превысят определенное значение (что относится к общему доступному максимальному размеру кучи). Если это так, единственный безопасный способ - это ограничить количество мгновенно сохраняемых ссылок на эти объекты. Кэш (пул) поможет, только если объединенные объекты могут быть использованы повторно. Иногда, если эти ресурсы состоят из массивов различной длины, например, они не могут быть легко использованы повторно. Таким образом, объединение может не сильно помочь здесь.

Как это обнаружить? Когда когда-либо будет большое давление на кучу больших объектов. Как это узнать? Используйте счетчик производительности .NET «Collection Count Gen 0 ... 2» одновременно. Если из большого объекта выделено слишком много больших объектов, все счетчики будут развиваться одинаково. Это означает, что в основном все коллекции являются дорогими коллекциями второго поколения. В этом случае, что-то должно быть сделано.

Что касается более мелких объектов, я бы позволил ГХ выполнять всю работу в коллекциях поколения 0 и не беспокоиться.