Стратегия или инструменты для поиска проблем с использованием "негерметичной" памяти в Delphi?

Одно старое приложение начало многократно потреблять память после обновления сервера. Использование памяти, похоже, растет с пределом до тех пор, пока программа не зависает.

В соответствии с FastMM4 и EurekaLog нет утечки памяти (кроме 28 байтов), поэтому я предполагаю, что вся память освобождается при завершении работы приложения.

Существуют ли какие-либо инструменты или стратегии, подходящие для отслеживания такой проблемы с памятью?

Ответ 1

  • Растущее потребление памяти - проблема приложения. Это не ошибка, которая может обнаружить FastMM4 или EurekaLog. Как с точки зрения зрения - приложение просто правильно использует память.
  • Используя AQTime, MemProof (трудно найти, D7 - последняя поддерживаемая версия (?)), SleuthQA (аналогично MemProof) или аналогичные профилировщики памяти, вы можете отслеживать использование памяти вне приложения в режиме реального времени.
  • Используя FastMM4, GetMemoryManagerState/GetMemoryManagerUsageSummary, вы можете отслеживать использование памяти из приложения. Выведите эту информацию в файл трассировки и проанализируйте ее после запуска. Или сделайте простую функцию обертывания для одной из приведенных выше процедур, которая вернет текущее использование памяти. И назовите его из IDE Debugger Evalute/Modify, добавьте в часы или вызовите OutputDebugString и просмотрите текущее использование памяти.

Обратите внимание, что если память используется некоторой DLL, вы можете не видеть ее использование памяти, используя (3). Используйте (2).

Анализируя использование памяти и задачи, выполняемые приложением, вы можете обнаружить, что приводит к увеличению использования памяти.

Ответ 2

С сентября 2012 года существует очень простой и удобный способ обнаружения утечек памяти типа "только время выполнения".

FastMM4991 представил новый метод LogMemoryManagerStateToFile:

Добавлен вызов LogMemoryManagerStateToFile. Этот вызов регистрирует сводку состояние диспетчера памяти в файл: общая выделенная память, служебные данные, эффективность и разбиение выделенной памяти по классу и типу строки. Этот вызов может быть полезен для обнаружения объектов, которые не обязательно протекают, но задерживаются дольше, чем должны.

Чтобы обнаружить утечку во время выполнения, вам понадобятся только эти шаги

  • добавить вызов LogMemoryManagerStateToFile('memory.log', '') в том месте, где он будет вызываться через интервалы
  • запустите приложение
  • откройте файл журнала с помощью программы tail (например, BareTail), которая будет автоматически обновляться при изменении содержимого файла.
  • просмотрите первые строки файла, они будут содержать выделения памяти, которые занимают наивысший объем памяти
  • Если вы видите, что класс или тип памяти постоянно имеют все большее число экземпляров, это может быть причиной утечки.

Ответ 3

AQTime (коммерческий инструмент, который является довольно дорогим) может сообщать о вашем использовании памяти, вплоть до строки исходного кода, которая выделяет каждый объект. В случае очень больших сценариев использования памяти вы можете захотеть, чтобы функция AQTime показывала количество объектов и размер (общий плюс индивидуальный размер экземпляра) для каждого объекта. AQTime отлично поработал у меня, начиная с Delphi 7 и всех последующих версий, включая вашу версию (2006) и последние версии (XE и XE2).

По мере увеличения использования памяти программы AQTime может использоваться для захвата "моментальных снимков" кучи времени выполнения, которую вы можете использовать для понимания использования памяти вашим приложением; Что создается и сколько из каждого объекта существует. Даже когда утечек не существует, очень важно понимать поведение во время выполнения вашего приложения с точки зрения объектов, которые он создает и управляет, и AQTime - это самый мощный инструмент, который я знаю для пользователей Delphi.

Если вы хотите перейти на Delphi XE/XE2, у вас может быть включенная легкая версия AQTime, если это так, проверьте ее. Если нет, я рекомендую вам попробовать их демо. Я не знаю о каких-либо бесплатных или альтернативных версиях с открытым исходным кодом, которые могут предоставить те же функции.

Малая функциональность может быть собрана вручную вручную, написав много сообщений о трассировке или используя полнофункциональный режим FastMM. Если вы могли бы написать полный дамп использования вашей памяти в очень большой файл, вы могли бы написать некоторые инструменты для синтаксического анализа и создать сводку. В этом случае проблема с FastMM заключается в том, что вы будете утоплены в подробной информации, не имея возможности извлекать точно сводную информацию, которая поможет вам понять вашу ситуацию. Таким образом, вы можете попытаться написать свой собственный инструмент, чтобы суммировать использование памяти. В одном приложении у меня было несколько компонентов, которые, как я знал, будут использовать много памяти, я написал диалоговое окно в мое приложение, которое показывало текущее использование памяти этими большими объектами памяти-blob-of-data.

Ответ 4

Вы когда-нибудь думали об утечке, которая вызывает IDE... она такая огромная!!!

В моем случае (2 ГБ ОЗУ) я делаю следующий... 1. Откройте IDE 2. Оставьте его сведенным к минимуму в течение примерно шести часов 3. Посмотрите, как используется физическая память.

Результат: В то время как IDE запущена (помните, что я также выполняю проверку, сводя к минимуму), он получает все больше и больше ОЗУ... до тех пор, пока не будет больше свободного места. Он получает все 2 ГБ ОЗУ + весь файл архива на жестком диске (он настроен на макс 4 ГБ) За менее чем шесть часов (ничего не делая на IDE) он пытается использовать более 6 ГБ.

Это называется утечкой памяти, запутанной IDE... я не печатаю никаких букв на IDE, не компилирую ничего, даже не открываю какой-либо проект... просто откройте IDE и минимизируйте его... оставьте компьютер, ничего не делая на нем около шести часов, а среда IDE потребляет 6 ГБ памяти.

Конечно, после этого IDE начинается с раздражающих сообщений SystemOutOfMemory... и я должен убить его... тогда все, что 6 ГБ освобождены!!!

Когда на аду это будет исправлено?

Обратите внимание, что у меня есть все исправления, я также тестировал без применения каждого исправления/исправления и т.д.

Лучшее, что я получил, это отключение некоторых опций в Инструментах, таких как тот, который подчеркивает плохой код и т.д.... так что, черт возьми, этот параметр имеет какое-то влияние... Я не набираю ничего на IDE (на тесты)... и если у меня есть это, то утечка памяти будет значительно уменьшена...

Конечно, если я использую IDE (писать код в открытом проекте), даже не компилируя/не запуская его... вещь идет намного хуже... утечка памяти до 6 ГБ может быть достигнута менее чем за час, иногда происходит через 15 минут с исходного кода Copy/Paste.

Кажется, не будет решения за короткое время!!!

Итак, я получил следующее решение, которое отлично работает: -Закройте среду IDE, чтобы открыть ее каждые 15 минут или менее.

Уродливое решение, я знаю... но работает!!!