Мы видим много фрагментации виртуальной памяти и ошибок памяти, а затем она достигает предела 3 ГБ.debug = true в web.config = ПЛОХАЯ вещь?
Отладка компиляции установлена в true в файле web.config, но я получаю разные ответы от всех, кого я спрашиваю, делает ли отладка установленным значением true, чтобы каждый aspx собирался в случайные области ram, таким образом, фрагментируя этот ram и в конечном итоге вызывая проблемы с памятью?
AFAIK «debug = true» не вызывают ситуации, о которой вы упомянули.
У меня была такая же проблема с приложением ASP.NET, которое создавало изображения на лету.
поэтому я думаю, что у вас есть проблема с не утилизированными ресурсами.
Если вы разворачиваете свои файлы aspx с файлами с кодом на сервер. Он будет скомпилирован один раз, когда запрос поступит в aspx. то он будет храниться в кеше до тех пор, пока файл не изменится.
Флаг отладки должен быть установлен в false в web.config, если только вам не нужно отлаживать приложение.
Запуск в режиме отладки может несколько увеличить использование памяти, но вряд ли это будет серьезной проблемой, о которой вы говорите. Тем не менее, вы должны установить значение false, чтобы эллимировать эффект, который у него есть, и посмотреть, можете ли вы заметить какие-либо улучшения.
При запуске в режиме отладки сборщик мусора работает по-разному. Время жизни переменных расширяется из фактического использования в область действия переменной (чтобы показать значение в отладчике). Это заставляет некоторые объекты жить дольше, чем собирать мусор.
Компилятор не оптимизирует код при компиляции в режиме отладки, а также добавляются дополнительные инструкции nop, так что каждая строка кода содержит по крайней мере одну инструкцию, в которой может быть размещена точка останова.
Выброс исключения занимает значительно больше времени в режиме отладки. (Тем не менее, обычно код не должен генерировать исключения, которые часто.)
Скотт Гатри (менеджер команды разработчиков ASP.NET) имеет interesting post about it.
Наиболее важные моменты, почему вы не должны оставлять отлаживать = «истина» являются:
Он также упоминает флаг <deployment retail=”true”/> в machine.config, что позволяет глобально переопределить отладки = «истинный» флаг всех приложений, работающих на машине (например, на производственном сервере).
Update: развертывание веб-приложений с debug="true" по-прежнему плохо, как вы можете прочитать в Scott Hanselman's recent blog post:
Вот почему отлаживать = «истина» плохо. Серьезно, мы не шутим.
Важное примечание. Вопреки тому, что иногда считается, установка retail = "true" в элементе не является прямым противоядием отладки = "истина"!
На производственных системах всегда устанавливается Debug = false. Поскольку флаг предполагает, что при отладке системы разработки она должна быть установлена в true.
Этот флаг не имеет ничего общего с проблемой фрагментации памяти.
Это абсолютно может повлиять на память, просто взгляните на некоторые счетчики perfmon и выполните сравнение с обеими конфигурациями.
Если на вашем сайте много файлов, я буду более озабочен диском io в папке temp asp.net.
пару вопросов ...
Почему бы не использовать несколько конфигураций?
Web.Debug.Config - Были ли отладка на Web.UAT.Config - Независимо от ваших предпочтений Web.Release.Config - Have Debugging выключен
Таким образом, вы можете свести к минимуму ошибки конфигурации регрессии, как разработчик проверка web.config in с debug = "true"
В моей компании стандартная политика, что все производственные веб-серверы имеют тег развертывания, установленный в machine.config. Это экономит много головных болей. – Chris