Пул приложений IIS использует слишком много памяти

У нас есть IIS, работающий на двух серверах (IIS8 и 10), и в последнее время мы сталкиваемся с очень высоким потреблением памяти нашими приложениями ASP.NET WebForms, к которым чаще всего обращаются через страницы aspx.

Что происходит, так это то, что со временем наши пуллы приложений потребляют все больше и больше памяти, пока физическая память на сервере (64 ГБ) практически не заканчивается. Это определенно ненормально.

Мы пытались выяснить, почему это происходит, но у нас кончились идеи. Неясно, является ли это утечкой памяти в нашем приложении или нормальным поведением, поэтому, возможно, кто-то сможет прояснить этот вопрос.

Факты:

• Со временем пуллы приложений резервируют И ИСПОЛЬЗУЮТ все больше и больше памяти, которая не освобождается (диспетчер задач говорит, что как рабочий набор, так и размер коммита очень высоки, так что это действительно используется/удерживается, верно?)

• Профайлеры памяти, такие как ANTS, .dotMemory, .NET MemoryProfiler, сообщают, что потребление управляемой памяти довольно низкое, скажем, 20-200 МБ, и показывают много неконтролируемой памяти, которая используется, но свободна.

• Они не дают нам никаких подсказок о том, что может вызывать использование неконтролируемой памяти, даже с помощью снимков и детализированных методов профилирования.

• Если мы “нажимаем” на главной странице клавишу F5, не освобождая ее, мы можем увеличить потребление памяти до 2-5 гигабайт за одну минуту. Это немного сумасшествие.

• Мы знаем, что IIS/пуллы приложений склонны резервировать память в оппортунистическом режиме, чем больше доступно памяти, но это слишком много.

• Единственное, что мы видим, это то, что главная страница, похоже, удерживается в памяти со своими элементами управления и объектами ComponentModel, но нигде в профилировщиках памяти нет единой ссылки на какие-либо из наших объектов страниц или классов собственного пространства имен.

• Потребление памяти, по словам некоторых, в прошлом году было нормальным и останавливалось на уровне 2-3 гигабайтов в общем, но теперь мы не можем воспроизвести это с помощью старой версии приложения.

• Это происходит и на свежей локальной установке IIS под WIN10.

• Приложение собрано в режиме релиза, оптимизировано, в данный момент скомпилировано в одну DLL, также пробовали без этого, флаг трассировки включен, размер 5 МБ.

Кажется, нам нужно разобрать приложение, разделить его на несколько модулей и посмотреть, как они ведут себя. Собранные во время выполнения сборки/библиотеки могут, но не должны быть проблемой. Мы на самом деле не ссылаемся на столько много (FreeTextBox, Microsoft ReportViewer, SharpCompress, Crystal Reports, AjaxControlToolKit 15), мы уже удалили все, кроме CrystalReports/AjaxControlToolKit, чтобы посмотреть, что произойдет, но ничего не изменилось.

Мы также используем много элементов управления WebForms, включая таймеры и UpdatePanels иногда.

Мы также не знаем, как найти виновника, используя профайлеры памяти, предполагая, что есть скрытая ссылка, которая вызывает удержание одной или нескольких страниц aspx в памяти, потому что экземпляры классов .NET никогда не показывают никаких ссылок на что-либо.

Мы были бы рады получить ЛЮБУЮ подсказку о том, что мы могли бы неправильно понять относительно резервирования памяти или того, как устранить эту проблему с потреблением памяти.

Большое спасибо за уделенное время!

ПОПРАВКА (забыл упомянуть):
– Мы добавили GC.Collect/WaitForPendingFinalizers/GC.Collect в нашу функцию Page_Load на стартовой странице, чтобы посмотреть, поможет ли это, и это действительно помогает на некоторое время или немного, пока не возникнет другая ситуация давления (с F5), когда потребление памяти снова резко возрастает.

Когда GC.WaitForPendingFinalizers помогает, это может быть признаком использования памяти потоками. Если вы запускаете новый отдельный поток в page_load, он может использовать много памяти. Начните диагностику проблемы, проверив количество потоков в диспетчере задач.