Использование памяти сайта ASP.NET довольно высокое

Может быть много причин для вашего большого использования памяти, но сборка мусора в .NET - очень точная вещь. То есть это много для вас, но иногда не так, как вы ожидали.

В частности, он может очищать только те объекты, на которые нет активных ссылок, поэтому, если вы закончили работу с классом, но что-то еще имеет ссылку на него, вы захотите удалить эту ссылку, чтобы GC мог восстановите эту память для вас. Кроме того, если у вас есть неактивные открытые соединения (например, с БД или чем-то еще), не забудьте закрыть и удалить их. Обычно мы заключаем такие объекты в , используя блоки , например:

using(SqlConnection conn = new SqlConnection(myConnString))
{ ...rest of code here }

Это автоматически закрывает и удаляет соединение. Это реализовано как блок try ... finally, поэтому соединение будет закрыто, даже если в блоке using возникнет исключение.

Кроме этого, ответ будет «профиль, профиль, профиль», пока вы не найдете свою утечку / узкое место / что угодно.

Есть несколько вещей, на которые вам следует обратить внимание:

Прежде всего, используете ли вы сессии? Они в proc или SQL сессиях? Если они в процессе, то какой таймаут установлен? Если у вас очень долгий таймаут, это может объяснить, почему вы используете так много памяти (пользовательские сессии будут храниться долгое время).

Во-вторых, утилизация объектов. Сборщик мусора .NET избавится от ссылок за вас, но когда вы создаете объекты, реализующие интерфейс IDisposable , вы всегда должны использовать ключевое слово using.

using(Foo foo = new Foo())
{
    ...
}

это эквивалентно тому, чтобы сделать :

Foo foo;
try
{
    foo = new Foo();
    ...
}
finally
{
    foo.Dispose();
}

и это гарантирует, что вы эффективно утилизируете свои объекты.

Если вы все еще не можете найти ничего очевидного в своем коде, вы можете профилировать его, начиная с методов, которые вызываются чаще всего. Информацию о хороших профилировщиках можно найти здесь. Это определенно приведет вас к источнику проблемы.

Утечки памяти в .NET все еще возможны. Это правда, что по большей части вам не нужно освобождать объекты (есть несколько исключений, таких как объект Graphics), но если вы сохраните ссылки на них, они не будут собираться сборщиком мусора, потому что на них по-прежнему ссылаются.

Если сборщик мусора видит, что на объект ссылаются где-то в любом месте вашего приложения, он не удалит его.

Прочтите статью Code Project об утечках памяти .NET и о том, как их найти и исправить.

Если ваше приложение ASP.NET использует события (а какое из них не использует), , то вы должны убедиться, что отписались от события .

Практическое правило:

Если вы используете + = для подписки на событие, тогда вам необходимо использовать - = в Dispose () метод отказа от подписки.

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

Используйте профилировщик памяти (либо в дампе памяти, либо в вашей реальной среде), когда ваша память превышает эти 500 МБ, чтобы понять, какие объекты занимают все это пространство.

При профилировании в среде разработки вы можете увидеть, что один конкретный тип объекта растет только при просмотре вашего сайта, в то время как другие остаются неизменными в глобальном масштабе.

Хотя это правда, что вам не нужно явно освобождать память, и сборщик мусора сделает это за вас, возможно, что код непреднамеренно удерживает ссылку на объект, чтобы предотвратить его собрано - это по сути утечка памяти.

В ASP.NET объекты остаются «живыми», пока на них ссылается кеш приложения и сеанса. Не зная ничего о вашем приложении, я бы посоветовал вам получить профилировщик памяти и более внимательно посмотреть, что именно находится в памяти, и удерживает ли кеш приложения или сеанса то, чего не следует.