2017-02-14 11 views
-2

У нас есть довольно сложное приложение Delphi, в котором используются сборки .NET. Мы используем FastMM в качестве нашего диспетчера памяти.Приложение для рабочего стола Delphi для Windows -> 513 МБ использования памяти при запуске -> 32.1 МБ после 50 минут незанятого состояния

Мы использовали исключения EOutOfMemory. Поэтому я уже некоторое время изучаю это. Мы подозревали, что у нас есть круговые ссылки между объектами Delphi. Или, возможно, некоторые .NET-объекты, содержащие ссылки на объекты Delphi, не позволяя им быть выпущенными.

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

Но сегодня по чистой случайности я кое-что обнаружил. Когда наше приложение запускается, диспетчер задач сообщает ca. 513 МБ Используемая память. Я только что запустил его, но мне пришлось отправиться на обед. Когда я вернулся, случайно, я заметил, что приложение теперь использует только 75 МБ. Странно я думал, должно быть, разбился или что-то, что я предполагал. Нет, совсем нет, приложение функционировало отлично. Что я наделал -> Ничего. Просто позвольте ему работать без дела. Наше приложение представляет собой приложение для настольных компьютеров. Не много происходит, пока он находится в режиме ожидания.

Итак, я затем начал смотреть дальше. Воспроизводимость. Потребление памяти начинает уменьшаться в больших прыжках по прошествии времени. После ок. 50 минут он достиг 32,1 МБ !!!

Я контролировал счетчики производительности сборщиков .NET Garbage и не было никаких больших изменений. Поэтому я подозреваю, что проблема заключается в стороне Delphi ->, которая указывает на FastMM.

Я не специалист по FastMM. Я убедился, и FullDebugMode не включен. Кто-нибудь еще испытал что-то подобное? Любые подсказки/идеи, которые могут быть неправильно сконфигурированы в FastMM?

Спасибо, миллион!

+0

@DavidHeffernan У вас, похоже, много опыта работы с менеджерами Delphi-Memory. :-). Был бы очень благодарен, если бы вы могли прокомментировать, если у вас был подобный опыт. Спасибо! – santiagoIT

+4

Здесь вы не можете задавать вопросы конкретным пользователям, и вы не можете их пинговать с помощью @ notation, если только они не комментировали первый или не комментируют их ответ. Это не сайт для социальных сетей, и вы не получаете персональную техническую поддержку от вашего предпочтительного пользователя. –

+0

@KenWhite Спасибо за информацию! Хорошо знать. Ну, надеюсь, он столкнется с этим вопросом.Я знаю из других вопросов о том, что Дэвид использует свой собственный MemoryManager и попробовал несколько вариантов. Поэтому его вклад был бы весьма ценным. – santiagoIT

ответ

1
  1. ОС иногда идентифицирует неиспользованный ОЗУ простоя приложения, чтобы освободить его для других приложений, то он не учитывается больше в ресурсе, потребляемой приложением.

  2. В таком гибридном приложении большая часть памяти зарезервирована картой .Net, для ее сборщика мусора, я думаю. GC будет работать в режиме ожидания и освободить/сфотографировать его память. Возможно, это и произошло. Добавьте в приложение несколько журналов: monitor the actual FastMM4 heap consumption.

  3. Возможно, произошла утечка памяти, и вы достигли предела в 32 ГБ для 32-битного процесса. Попробуйте set the 3GB flag for the exe. Или переключитесь на 64-битный исполняемый файл, который сделает ваш .Net-код счастливым. Запустите FastMM4 in memory leak reporting mode, чтобы убедиться, что приложение безопасно.