Почему # Байты во всех кучах считаются хорошей мерой для общей управляемой кучи

Question

Я контролирую мою проблему с высокой памятью .NET с использованием счетчиков производительности. Для измерения памяти .NET мне показалось, что # Байты во всех часах производительности Heaps обеспечивают общее использование управляемой памяти. Однако согласно MSDN, этот счетчик не содержит Gen 0 Heap Size.

Отображает сумму Gen 1 Размер кучи, Gen 2 Размер кучи и больших объектов счетчиков Размер кучи. Этот счетчик указывает текущую память , выделенную в байтах на кучи мусора.

Если приложение .NET выделяет много памяти в генераторе 0, то разве это не должно учитываться в # Bytes во всех Heaps? Я знаю, что есть отдельный счетчик для размера кучи Gen 0, но так же для Gen 1, Gen 2 и LoH.

Answer 1

Это довольно субъективно. Но когда вы задаете вопрос «сколько памяти использует мое приложение .NET», тогда вас обычно не интересуют распределения памяти, которые живут миллисекундой или меньше. «Рабочая память», так сказать. Используется для объектов, которые хранятся в сегменте кучи gen # 0.

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

Не равные нулю шансы на то, что другая практичность сыграла свою роль. Если счетчик также будет показывать gen # 0, это будет дико меняющееся число, которое очень быстро отскакивает вверх и вниз. В основном белый шум в графике, не очень дружелюбный.

Answer 2

Обратите внимание, что «Gen 0 Heap Size» не говорит вам, сколько байтов занимают объекты в куче Gen 0 - оно всегда предварительно распределено до определенного размера и не увеличивается во время распределения. Число просто говорит вам, сколько памяти выделено для распределений Gen 0.

В Gen 0 нет реального способа получить размер объектов - это слишком высокий трафик, чтобы он того стоил. В сравнении, как кучи Gen 1, так и Gen 2 можно только когда-либо заселять во время сбора мусора - тривиально установить счетчик производительности там. У LOH есть похожие рассуждения - вы выделяете достаточно большие объекты, поэтому стоимость прироста счетчика производительности в основном тривиальна.

Не забывайте, что объекты Gen 0 не могут оставаться в Gen 0 в течение долгого времени - в течение следующей коллекции они либо будут освобождены, либо переведены в Gen 1. Трудно представить сценарий, в котором Gen 0 куча сильно заселена - на самом деле, IIRC, она масштабируется относительно кэша процессора; в то время как это не совсем «мало» на современных процессорах, это также ясно показывает намерение - это книга с царапинами для нескольких небольших объектов, которые либо выброшены почти сразу, либо удалены.