Освобождение памяти в веб-сервисе

Есть такая проблема: в веб-сервисе загружается файл пакетами, файл потом обрабатываются и сильно повышают потребление памяти процессом. В веб-сервисе используются библиотеки других команд, по обработке файлов и подозрение на эти библиотеки. Повлиять на на них очень сложно. Будем считать что веб-сервис ни в чем не виноват, а виноваты эти библиотеки и без этих библиотек не обойтись и пофиксить в этих библиотеках нет возможности.
У клиентов есть визуальные средства контроля ресурсов и они сразу видят, что веб-сервис потребляет много памяти и это их напрягает.
Проблема в том что мне надо наглядно показать что веб-сервис отработал и освободил память.
Из идей только одна: в веб-сервисе оставить только функциональность приема пакета данных и сохранение этих данных во временный файл на сервере (так щас и работает). А всю функциональность по обработке этого файла (там на самом деле очень много работы делается с этим файл, я для простоты говорю что это обработка файла) вынести в серверную задачу и запускать эту задачу из веб-сервиса, а после выполнения работы убивать задачу и память освобождать таким образом.
Может у кого-нибудь будут идеи получше?

0

Alim96, Вы статью прочитали? Там хорошо всё рассказано и можно понять, что на расход памяти можно забить. Оно само там всё работает и когда надо очищается. Запустите несколько копий и проследите как будет меняться выделение памяти для процесса. Если не будет хватать памяти какому нибудь процессу, GC начнёт очистку сам...

Добавлено через 13 минут
Alim96,

Сообщение от Andrey-MSK что на расход памяти можно забить

Предварительно убедившись что нет утечек памяти из-за ошибок.

1

Ограничивать объем GC почти всегда плохая идея.
Вмешиваться в работу GC не надо, не ваш случай

Скорее всего проблема происходит из-за больших объектов, которые вы загружаете в память.
Большие объекты НАДОЛГО помещаются в Large Object Heap (LOH).
GC очень не любит чистить LOH, это долго и 'дорого'.
Поэтому он и не будет чистить LOH так долго, как только может (и это правильно).
(Приложение можешь съесть до 70% доступной памяти на устройстве и это в пределах нормы)

Если приложение не крашится, то оно нормально работает.

Но оптимизировать можно.
Попробуйте не создавать большие объекты (почти всегда это очень большие string).
Возможно вам помогут стримы, структура Span<T>, StringBuilder или если есть возможность редактировать файл выборочно (по строкам, блокам) то поступайте так.

2

Andrey-MSK, статью конечно читал. Прежде чем сюда написать она попадалась мне часто.
Я просто решил еще поспрашивать че можно сделать. Потому что просто забить всегда можно)

Добавлено через 18 секунд
А так всем спасибо за помощь и советы

0

Сообщение от Alim96 еб-сервис ни в чем не виноват, а виноваты эти библиотеки и без этих библиотек не обойтись и пофиксить в этих библиотеках нет возможности.

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

Добавлено через 44 секунды

2

0

kolorotur,

Сообщение от Alim96 Из идей только одна: в веб-сервисе оставить только функциональность приема пакета данных и сохранение этих данных во временный файл на сервере (так щас и работает). А всю функциональность по обработке этого файла (там на самом деле очень много работы делается с этим файл, я для простоты говорю что это обработка файла) вынести в серверную задачу и запускать эту задачу из веб-сервиса, а после выполнения работы убивать задачу и память освобождать таким образом.

примерно об этом я и говорил тут

0

Сообщение от Alim96 Может у кого-нибудь будут идеи получше?

Без четкого понимания что отжирает память -- не подсказать. Вариантов может быть несколько:
1. Там всё оптимально, просто сама задача жрет много ОЗУ. Маловероятно, но исключать стоит только после разбора.
2. Виновата либа. Идеально -- переписать. Менее идеально -- ваш вариант с отдельным процессом, который будет стартовать, выдавать результат и высвобождать ресурсы после. Проблема в том что внедрение не тривиально (межпроцеросный обмен данными не самая простая задача), да и потенциально можете назапускать 100500 висяков что уже 100% приговорит сервак.
3. Либа не причем. Из вариантов не правильное использование (скажем забыли какой-нибудь Dispose или Clear), либо вообще утечка в другом месте (кеш какого-нибудь sql).

0