measuring memory usage

[Malaja]

Постановка задачи:
надо проверитъ наличие / отсутствие утечек памяти с помощью теста:
- какое-то измерение памяти на старте: mem_start
- стартовать несколько ехе-шников,
- создать по определенным правилам некоторые объекты
- остановить ехе-шники, удалить созданные объекты
- какое-то измерение памяти в конце: mem_end
- анализ mem_end - mem_start

Начала смотреть, чем бы померять использование памяти - народ (литература) предлагает, в основном, следующее:

1) System.Diagnostics.PerformanceCounter("Memory")
2) System.GC.GetTotalMemory
3) Process.PrivateMemorySize64
4) Process.WorkingSet64

Смысл измерений с помощью 2) не понимаю - мусоросборник как таковой обрабатывается виндой и все равно будет аккуратно когда-нибудь оприходован (хотя может я и неправа...).

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

[Finch]

Ирин, ты же вроде как в .NET работаеш? Зачем проверять течи?

А вообше, для этого есть инструменты. Которые предназначены как раз для ловли блох.

[Malaja]

Вить,
дело в том, что сам тест на шарпе, а используемый код - на с++, ну и вокруг кода есть оболочка (все как всегда).
Народ хочет видеть несколько вещей сразу:
1) корректность оболочки + самого исходного кода (на это есть куча тестов как таковых)
2) в связи с тем, что клиенты получают результирующий продукт в виде длл-лины на шарпе, с которой потом работают, народ хочет знать, сколько памяти кушает эта самая длл-лина (чистый код проверяется на вшивость в виде дыр в памяти и общего расхода памяти отдельно) плюс остаются ли где-то какие-то дырки от самого исходника.

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

насчет отлова memory leaks я вообще пока не соображу, как я их должна ловить в моем шарп-тесте (это я буду обсуждать с коллегой завтра) - теоретически это дело других тестов.
А вот посмотреть расход памяти - это таки нормальное задание, но надо знать, с каким иснтрументом его лучше всего решать.

[resource]

GetProcessMemoryInfo. Так....до кучи

[Malaja]

resource,
я ее сейчас посмотрела - в шарпе вся инфа из структуры PROCESS_MEMORY_COUNTERS доступна из класса Process - разработчики языка  тут упростили процесс получения информации.

[Finch]

Malaja, В свое время я как-то видел статью. В которой предлагалось переопределять операторы new, new [], delete, delete []. И в них вписывать уже код, который будет следить за памятью. Собственно стороние инструменты именно так и поступают. Правда на уровне malloc, free. Внешние WinAPI функции дают только размеры кучи.
Честно говоря, как это будет выглядеть в .NET я не совсем представляю.

[Malaja]

Да вот и я пока это толком не представляю - тут же за все отвечает сборщик мусора, поэтому когда в реальности будет убит твой объект (если ты сам не позаботился об этом, вызвав dispose), не знает никто, даже дядя Билл, родоначальник всего этого. 

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

Код:

WorkingSet64 	*** after test = 35483648 	*** before test = 35483648 	*** diff = 0
PerfomCounter 	*** after test = 1800 		*** before test = 1811 		*** diff = -11
GC_TotalMemory 	*** after test = 1658912 	*** before test = 1634080 	*** diff = 24832
PrivMemSize64 	*** after test = 119386112 	*** before test = 113500160 	*** diff = 5885952

1) Т.е. общая (физическая) память вообще не изменяется (WorkingSet64 ).
2) Счетчик эффективности (PerfomCounter) изменился на пару единиц, но это ничего не говорит о реальном использовании памяти.
3) В сборщике мусора (GC_TotalMemory), как и ожидалось, накопилась куча ненужных объектов
4) Личная память процесса, к которой никто сторонний доступа не имеет (PrivMemSize64 ), выросла. Но опять же это логично - там создавалась куча пользовательских объектов.

Короче, пока никак все это связать (и увидеть логику в использовании в данном конкретном случае) не выходит. Еще немного пороюсь и пойду беседовать с постановщиком задачи на тему "а надо ли нам это"

Вот нашла статью об управлении памятью:

http://msdn.microsoft.com/en-us/library/f144e03t.aspx

[Dimka]

Malaja, а ты класс GC пинай перед анализом памяти:

Что-то в духе:

Код: (Text)

GC.Collect();

Я лично таким нехитрым способом удерживаю расход памяти в пределах 10-30 Мб при частых операциях создания/удаления. А если этого не делать, он и 100 Мб и 1 Гб скушать способен.

[Malaja]

Дим,
дело в том, что пинать GC должна та длл-лина, которая поставляется клиенту.
Мое дело было бы посмотреть на то, чем закончится использование этой самой длл-лины.
Но тут тоже все не так просто - в тесте тоже создается куча объектов типа array, hashtable, собственные классы и т.д. для хранения данных. И эта орава тоже неплохо кушает память! И как их разделить, дабы сказать с достаточной определенностью, кто оставил за собой шлейф проблем? Никак...

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

Самое красивое было бы - решение, которое описал в своем посте Витя (и именно это имел в виду коллега - при каждом new в таблицу вносим инфу о новом поинтере, при каждом delete из таблицы этот поинтер удаляем. На выходе имеем список того, что не было убрано) , но для этого отсутствует база, т.е. переопределенные операторы. new, delete и т.д. применяются в проекте в их родном виде. И исправить это уже не представляется возможным - размеры проекта огромны.