Пул приложений IIS, управление памятью

У меня есть служба RESTful WCF, размещенная на IIS 7.5. Когда вызывается какая-то операция, она возвращается почти сразу, но начинает сложную задачу, касающуюся комбинаторики и открытия больших файлов в памяти. После нескольких запросов около 50% памяти используется пулом приложений, хотя задачи уже завершены. Когда пул IIS восстанавливает память? Я попытался позвонить GC.Collect(), но ничего не произошло. Есть ли способ профилировать приложения, подобные этому? Я попробовал несколько профилировщиков, но они показывают только классы .NET, которые IIS использует для обработки запроса.Пул приложений IIS, управление памятью

источник

2014-01-30 Qué Padre

Не могли бы вы показать какой-то код, как вы создаете и закрывать файлы в памяти –

@ShirazBhaiji К сожалению, я не могу опубликовать код здесь, но я попытался профилировать один и тот же код, добавив его в простое приложение и didn ' t найти утечки. –

Боковое примечание: непонятно, что вы ожидаете/жалуетесь - если ваши операции все еще продолжаются, почему вы ожидаете, что объекты будут выпущены? У вас есть основания полагать, что после завершения вашей «сложной задачи» все еще используется большое количество управляемой памяти (не смотрите на диспетчер задач, так как он не показывает% свободной управляемой памяти ...) –

Долгосрочные задачи обычно не подходят для веб-приложений, так как они тайм-аут/зависание веб-сайта/API
Возможно ли настроить фоновое задание для асинхронного запуска сайта IIS? Таким образом, вы можете подтолкнуть эти медленные задачи к очереди и обработать их в фоновом режиме

Я думаю, что использование памяти в процессе является проблемой, но не рассказывает всю историю, что вам удалось профайл до сих пор? У вас незакрытые связи затянуты? Вы создаете экземпляры нескольких классов, которые не удаляются эффективно? Я бы посмотрел, чтобы профилировать план выполнения вызова больше, чем использование памяти, так как это может привести к дополнительным вызовам о том, где находятся элементы.

Когда вы говорите 50% -ную память, сколько мы говорим на самом деле в мб? IIS может быть немного жадным/ленивым, когда ему не нужно сдаваться RAM

источник

2014-02-03 16:00:19 finman

ну, 50% 32 Гб здесь ... =) Я скопировал код в консольное приложение и использовал несколько профилографов. Итак, в основном это приложение делает то же самое, но без утечек. =) –

Возможно, это не утечка, просто не выпуская то, что ей не нужно, пока это не произойдет. Можете ли вы извлечь методы, используемые в dll, затем вызвать это из службы? Это может помочь лучше понять профиль приложения, даже если это просто симулировать некоторую начальную нагрузку на услугу. Это должно проявлять такие вещи, как закрытые соединения, большие объекты в куче не утилизируются правильно, а ссылки остаются открытыми. После того, как у вас есть это, вы можете посмотреть на сам сайт, чтобы попытаться выяснить, правильно ли оно устранено с этой целью, но профилирование IIS - это большая PITA, чем DLL. – finman

. Можете ли вы также посмотреть более подробно использование памяти, если вы смотрите в диспетчере задач. Вы можете добавить дополнительные столбцы, чтобы узнать, какие существуют различные типы размещения памяти: https://www.dropbox.com/s/j5iwlkrjjexy9sb/memory%20settings.png (это пример расширенного представления диспетчера задач) – finman

Сам рабочий процесс сам по себе не освобождает оперативную память. Вы можете настроить процесс на переработку по расписанию - это перезапускает процесс, освобождая память, не мешая работающим запросам.

Возможно, вы не должны этого делать - в основном .net держится за память, чтобы не перераспределять его для последующих запросов. Память доступна для повторного использования в рамках процесса WCF, и если память не используется, ОС выведет ее на экран и позволит ей повторно использовать ее, если это потребует другие процессы. См. Answer to When is memory, allocated by .NET process, released back to Windows для получения более подробной информации.

источник

2014-01-30 23:25:58 Rattle

Ну, сам запрос обрабатывается очень быстро, как я уже говорил. Если я переработаю пул - процесс, который был запущен по запросу, умрет. –

В чем конкретно проблема, вы получаете ошибки, связанные с памятью, или просто наблюдаете за использованием большой памяти в диспетчере задач? Если вы просто видите, что процесс держится в памяти без каких-либо других ошибок, это нормальное поведение, и вы не должны пытаться его изменить. BTW, если у вас длительный процесс, который выходит за пределы веб-запроса, рабочий процесс может быть не лучшим местом для его запуска, если только вы не предприняли шаги, чтобы остановить IIS, автоматически перерабатывая процесс. – Rattle

Yup, процесс, который запускается по запросу, является долговременным. Служба потребляет много памяти (я вижу ее в диспетчере задач), и мне нужно запустить другую службу сразу после, но для этого нет памяти. –

У меня была почти аналогичная проблема, и я решил ее использовать с помощью Castle.Windsor в качестве контейнера IoC, добавил класс клиента svc в контейнер с Transient Scope, и, наконец, я украсил класс svc: [ServiceBehavior (InstanceContextMode = InstanceContextMode.PerCall)].

Все остальные зависимые связки добавляются с помощью переходного Livestyle, что делает их зависимыми от их исполнителей. Я не уверен, что это поможет в вашей ситуации, учитывая тот факт, что вы используете большие файлы, но если что-то еще не удается, попробуйте реализовать IDisposable в большинстве разделов едоков памяти и проверьте, вызывается ли Dispose, когда это необходимо.

Надеюсь, что это поможет!

источник

2014-02-04 15:54:12

Я не совсем уверен, но я думаю, что фабрика услуг WCF по умолчанию возвращает класс svc клиента как singleton. –

Пул приложений IIS, управление памятью

ответ

Смежные вопросы