Приложение .NET внезапно испытывает резкий рост неуправляемой памяти

Question

Я запускаю приложение, которое показывает некоторые очень специфические проблемы.Он отлично работает в течение примерно 2,5 часов, затем внезапно неуправляемая память начинает расти и быстро расти.Примерно через полчаса происходит сбой приложения.

Приложение не использует неуправляемые библиотеки DLL.Это общение с внешним приложением.Он пишет с помощью сокета (используется через поток) и читает через поток WCF.

Я профилировал его с помощью ANTS.Внезапное изменение в неуправляемом использовании памяти очень поразительно;он остается идеально ровным навсегда, затем внезапно начинает увеличиваться и продолжает делать это с постоянной скоростью, пока не произойдет сбой приложения.Кажется, что ничего в управляемой памяти неуместно.

Учитывая, что я не использую преднамеренно неуправляемый код, трудно определить, откуда происходит утечка.ANTS не поможет.Трудно очистить код от проблем, когда он не увеличивается с самого начала (приложение все время простаивает, хотя оно и пингует свой сервер один раз в секунду через сокет с очень небольшим битом данных).

Чтобы повторить, приложение и сервер оба бездействуют в течение этого времени;он работает в изолированной тестовой системе (как на сервере, так и на клиенте).Клиент - тот, который протекает.

Answer 1

Возможно, вы захотите использовать DebugDiag для отслеживания утечек памяти и предоставления информации о том, что было выделено, сколько и из каких стеков вызовов.Вкратце:

Вскоре после запуска (или перезапуска) процесса выполните следующие действия:

1. Откройте DebugDiag.
2. Отмена из мастера.
3. Перейдите на вкладку «Процессы».
4. Щелкните правой кнопкой мыши нужный процесс.
5. Выберите «Монитор на наличие утечек».
6. Нажмите «ОК».

После того, как процесс запущен некоторое время, и проблема с памятью очевидна:

1. Перейти к DebugDiag
2. Если он еще не был открыт, отмена изМастер.
3. Перейдите на вкладку Процессы.
4. Щелкните правой кнопкой мыши по тому же процессу, что и часть # 1.
5. Выберите «Создать полный пользовательский дамп».
6. Запишите местоположение дампа.

Кроме того, если процесс перезапускается до захвата дампа памяти,Мониторинг утечек нужно будет снова включить.

После создания дампа:

1. Перейти к DebugDiag.
2. Перейти на вкладку «Расширенный анализ».
3. Выберите сценарий «MemoryAnalysis.asp» вверху.
4. Нажмите «Добавить файлы данных» внизу и выберите созданный ранее дамп.
5. Нажмите «Начать анализ»и просмотрите результаты.

Получив эту информацию, вы сможете определить, откуда идет выделение памяти, и, надеюсь, причину ваших проблем.

Выможно найти дополнительную информацию на следующих ресурсах:

• http://blogs.msdn.com/b/tess/archive/2010/01/14/debugging-native-memory-leaks-with-debug-diag-1-1.aspx
• http://www -01.ibm.com / support / docview.wss? uid = swg21307645

Answer 2

Мы в итоге нашли проблему.Оказалось, что у нас было сокетное соединение между ними, и во время фазы простоя мы отправляли пакет KeepAlive, чтобы предотвратить автоматическое отключение слушателя.Тем не менее, после простоя в течение определенного времени, в течение некоторого времени ожидания с WCF, сокет закрывался на стороне сервера.

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

Спасибо за весь вклад, но он был высоко оценен!