Назад | Перейти на главную страницу

Почему в IIS, на котором запущено приложение ASP.net, загрузка ЦП медленно увеличивается, резко падает, а затем поднимается до заданного уровня?

Смотрите изображение здесь: общая загрузка ЦП%

Эту тенденцию легко повторить, запустив автоматические нагрузочные тесты в приложении. После того, как загрузка ЦП стабилизируется на явно ограниченном уровне (~ 30%), время отклика приложений ОЧЕНЬ медленное.

Глядя на это, я имею в виду двух виновников:

  • Объекты, оказавшиеся в куче больших объектов. Это вызовет проблемы с производительностью веб-приложения, но не отобразится на счетчике времени сборки мусора. Однако я отклоняюсь от этого, поскольку это, как правило, связано с большим использованием памяти и исключениями / ошибками памяти, а не с использованием процессора.
  • Что-то не удаляется правильно, вероятно, потому, что это глобальный объект, на который они ссылаются при каждом запросе. Я думаю, это связано с конкатенацией строк, потому что это операция, которая чаще всего связана с высокой загрузкой процессора. Сложите эти улики вместе, и мое чутье подсказывает мне искать систему регистрации, используемую с приложением. Это объект, который будет обрабатываться при каждом запросе и имеет дело с большим количеством строк.

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

Спасибо за ответы. Я убедился, что для Debug установлено значение «False». Посмотрел память и% времени в счетчиках GC. Сразу после резкого падения ЦП использование памяти увеличивается на несколько минут, а затем снова снижается (сборщик мусора). Общий процент времени в GC невелик.

Я нашел дополнительную информацию в журнале системных событий. Резкие перепады ЦП соответствуют События IIS 1011:

У процесса, обслуживающего пул приложений% 1, произошла фатальная ошибка связи со службой WWW. Идентификатор процесса:% 2. Поле данных содержит номер ошибки.

Попробуйте также контролировать другие счетчики производительности. Мое первое предположение - проверить% времени в GC.