Я унаследовал веб-сайт, который использует много состояний сеанса. Недавно мы наблюдали постоянную высокую загрузку ЦП ~ 95-100% в течение длительного периода времени.
При отладке с помощью DebugDiag он показывает, что в куче больших объектов было ~ 3 ГБ, которые, как мне кажется, собираются сборщиком мусора в Gen 2 и могут быть причиной высокой загрузки ЦП.
У меня практически нулевой опыт отладки таких сценариев, но является ли вышеперечисленное правдоподобной причиной высокой загрузки процессора?
Спасибо.
Проверить, является ли сборщик мусора проблемой, можно с помощью монитора производительности и счетчика производительности «Память .NET \% времени в сборке мусора». Если у вас есть только один .NET-процесс на сервере, вы можете просто использовать экземпляр _total. В противном случае вам придется найти экземпляр с соответствующим идентификатором процесса и посмотреть его (хотя имейте в виду, что имя экземпляра для вашего приложения может измениться на лету, если какие-либо приложения запускаются или закрываются).
Если пики в этом счетчике соответствуют пикам ЦП, ваша проблема - сбор мусора - вам нужно будет искать утечки, выделять меньше объектов, держать вещи достаточно маленькими, чтобы они не попадали в LOH, храните их меньше времени, повторно используйте их , и / или устранить деструкторы. Каждая из этих вещей сократит время, затрачиваемое на хранение в GC. По иронии судьбы, слишком большое количество кэширования может сделать ваш сайт непоследовательно не отвечающим на запросы, поскольку кэшированные элементы в конечном итоге оказываются в куче 2, а обработка запросов приостанавливается, пока сборщик мусора просматривает каждый элемент в куче 2. По мере увеличения давления памяти частота этих блокировок увеличивается до тех пор, пока в конечном итоге ваши запросы полностью истощаются.