Причины утечки памяти веб-службы - PullRequest
2 голосов
/ 13 ноября 2008

У нас есть веб-сервис, который использует все больше и больше личных байтов, пока приложение не перестанет отвечать. Управляемая куча (в основном Gen2) будет показывать около 200-250 МБ, а частные байты - более 1 ГБ. Каковы возможные причины утечки памяти вне управляемой кучи?

Я уже проверил следующее:

  1. Полезные динамические сборки (сериализация в формате XML, регулярные выражения и т. Д.)
  2. Состояние сеанса (отключено)
  3. System.Policy. Очевидная утечка памяти (установлен SP1)
  4. Потоковая тупик (без использования соединения, только блокировка)
  5. Использование SQLOLEDB (с использованием SqlClient)

Какие еще источники я могу проверить?

Ответы [ 6 ]

2 голосов
/ 13 ноября 2008

Убедитесь, что ваше приложение выполняется в режиме выпуска. Если вы скомпилируете в режиме отладки и развернете его, просто создав экземпляр класса, для которого определено событие (событие даже не нужно вызывать), произойдет утечка небольшого фрагмента памяти. Создание достаточного количества этих объектов в течение достаточно длительного периода времени приведет к использованию всей памяти. Я видел веб-приложения, которые занимали бы всю память в течение нескольких часов просто потому, что использовалась отладочная сборка. Компиляция в виде сборки выпуска немедленно и навсегда устранила проблему.

0 голосов
/ 15 января 2019

Что бы это ни стоило, моя проблема была не с сервисом, а с HttpClient, который его вызывал.

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

После удаления клиента служба освободила память, как и ожидалось.

0 голосов
/ 11 апреля 2009

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

0 голосов
/ 04 апреля 2009

Сборка мусора не запускается до тех пор, пока не будет отклонен запрос памяти из-за недостатка доступной памяти. Это часто может сделать вещи похожими на утечку памяти, когда их нет рядом.

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

0 голосов
/ 13 ноября 2008

Я бы порекомендовал вам просматривать снимки стека в разное время и смотреть, что занимает память. Если ваше приложение использует Java, тогда jmap работает очень хорошо - вы просто даете ему PID процесса java.

Если вы используете что-то еще, попробуйте лямбда-зонд (http://www.lambdaprobe.org/d/index.htm).. Он не показывает столько деталей, но, по крайней мере, покажет вам использование памяти.

У меня произошла серьезная утечка памяти в моем коде JDBC, которая закончилась тем, что несколько лет назад я пропустил изменения в спецификации JDBC, которые я пропустил (в отношении заключительных операторов и т. Потребовалась комбинация Lamdba Probe, а затем jmap, чтобы локализовать проблему достаточно, чтобы решить ее.

Приветствия

-R

0 голосов
/ 13 ноября 2008

Также ищите:

  • Загружаемые COM-сборки
  • Соединения с БД не закрываются
  • Кэш и состояние (сеанс, приложение)

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

Что может случиться, так это то, что памяти достаточно, и Windows не подает сигнал на очистку вашего приложения. Это заставляет приложение выглядеть так, как будто оно использует все больше и больше памяти, потому что оно может, когда на самом деле система может восстановить память, когда это необходимо. SQL Server и Exchange делают это много. Идея состоит в том, чтобы вызвать ненужную очистку, когда есть много ресурсов.

Rob

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...