Пул приложений 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.

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

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

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

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

0
задан 20 July 2019 в 14:27
1 ответ

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

0
ответ дан 23 November 2019 в 22:45

Теги

Похожие вопросы