Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1]   Вниз
  Печать  
Автор Тема: measuring memory usage  (Прочитано 4827 раз)
0 Пользователей и 1 Гость смотрят эту тему.
Malaja
Команда клуба

de
Offline Offline
Пол: Женский

« : 03-05-2010 13:24 » 

Постановка задачи:
надо проверитъ наличие / отсутствие утечек памяти с помощью теста:
- какое-то измерение памяти на старте: 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
Спокойный
Администратор

il
Offline Offline
Пол: Мужской
Пролетал мимо


« Ответ #1 : 03-05-2010 14:05 » 

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

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

Не будите спашяго дракона.
             Джаффар (Коша)
Malaja
Команда клуба

de
Offline Offline
Пол: Женский

« Ответ #2 : 03-05-2010 14:53 » 

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

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

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

холоднокровней, Маня, Ви не на работе
resource
Молодой специалист

ru
Offline Offline
Пол: Мужской

« Ответ #3 : 03-05-2010 15:57 » 

GetProcessMemoryInfo. Так....до кучи
Записан
Malaja
Команда клуба

de
Offline Offline
Пол: Женский

« Ответ #4 : 04-05-2010 08:24 » 

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

холоднокровней, Маня, Ви не на работе
Finch
Спокойный
Администратор

il
Offline Offline
Пол: Мужской
Пролетал мимо


« Ответ #5 : 04-05-2010 11:51 » 

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

Не будите спашяго дракона.
             Джаффар (Коша)
Malaja
Команда клуба

de
Offline Offline
Пол: Женский

« Ответ #6 : 04-05-2010 12:35 » 

Да вот и я пока это толком не представляю - тут же за все отвечает сборщик мусора, поэтому когда в реальности будет убит твой объект (если ты сам не позаботился об этом, вызвав 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
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #7 : 04-05-2010 14:23 » 

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

Что-то в духе:
Код: (Text)
GC.Collect();

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

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
Malaja
Команда клуба

de
Offline Offline
Пол: Женский

« Ответ #8 : 04-05-2010 14:36 » 

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

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

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

Записан

холоднокровней, Маня, Ви не на работе
Страниц: [1]   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines