Утечка памяти при использовании Workflow 4.0 SqlWorkflowInstanceStore и PersistableIdleAction.Unload - PullRequest
Новая
       16

Утечка памяти при использовании Workflow 4.0 SqlWorkflowInstanceStore и PersistableIdleAction.Unload

2 голосов
/ 29 апреля 2010

Эта конкретная проблема сводит меня с ума. Интересно, сталкивался ли кто-нибудь с подобной проблемой. Если я загружаю рабочий процесс, затем выгружаю его и выполняю снимок памяти, результат будет предсказуемым - моего рабочего процесса больше нет в памяти. Однако, если я загружаю рабочий процесс и устанавливаю действие PersistableIdle равным PersistableIdleAction.Unload и позволяю рабочему процессу простаивать, рабочий процесс остается в памяти, даже если запускается действие Unload.

Я использовал ANTS Memory Profiler для устранения этой проблемы. Это выведенный график сохранения объектов, показывающий, что внутренний объект висит на моем экземпляре рабочего процесса.

альтернативный текст http://www.rohland.co.za/wp-content/uploads/2010/04/Workflow_retention_graph.png

Может кто-нибудь еще проверить эту проблему? Мой код соответствует следующему:

  1. Создание SqlWorkflowInstanceStore и настройка дескриптора владельца блокировки
    - в этот момент я делаю снимок памяти
  2. Создание экземпляра Workflow1
  3. Установить действие PersistableIdle
  4. Применение хранилища экземпляров к Workflow1
  5. Настройка обработчиков событий действий для Idle, Unload, UnhandledException и т. Д.
  6. Сохранить экземпляр рабочего процесса
  7. Запустить экземпляр рабочего процесса
  8. Ожидание, например, в режиме ожидания (вызвано активностью задержки)
  9. Убедитесь, что действие Unload запущено
    - В этот момент я делаю второй снимок памяти

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

Есть какие-нибудь подсказки?

1 Ответ

0 голосов
/ 30 апреля 2010

Похоже, интересная ошибка? У меня нет профайлера, о котором вы упомянули, поэтому пара вопросов.

  • Ваше расследование вызвано серьезными проблемами использования памяти?

  • Насколько вы уверены, что действие выгрузки действительно завершено во время профилирования (против асинхронного и т. Д.)?

  • Кажется, что асинхронная цепочка в порядке, но TdsParserStateObject, вероятно, будет реальной утечкой объекта. Я заметил, что класс имеет метод Dispose (), но не реализует IDisposable. Таким образом, другая идея заключается в том, что Dispose () используется для ручного «сброса» или «рециркуляции» объекта в какой-то определенный момент времени, но этот момент времени оказывается «еще (время выгрузки), но позже», например. ленивая переработка. Позволяет ли ваш профилировщик увидеть, увеличивается ли число TdsParserStateObjects с течением времени, чтобы указать на реальную утечку? В отличие от «просто конечного числа объектов, а не настоящей утечки».

...