Приложение Asp.net работает медленно, но ЦП загружен не более чем на 40%
У меня странная ситуация на производственном сервере. Подключение для asp.net ставится в очередь, но процессор загружен только на 40%. Также база данных отлично работает на 30% ЦП.
Еще немного истории, как просили в комментариях:
- В часы пик на сайты приходят около 20 000 посетителей в час.
- Сайт представляет собой приложение asp.net webforms с большим количеством AJAX / POST.
- Сайт использует много пользовательского контента.
- Мы измеряем производительность сайта с помощью тестовой страницы, которая попадает в базу данных и веб-сервисы, используемые сайтом. Эта страница обслуживается в течение секунды при нормальной загрузке. Мы определяем приложение как медленное, если запрос занимает более 4 секунд.
- Из измерений мы видим, что время соединения быстрое, но время обработки велико.
- Мы не можем точно определить медленный ответ на единичный запрос, сайт работает нормально в обычные часы, но становится медленным в часы пик
- У нас была проблема, связанная с ограничением ЦП (так называемая работа на 100%), мы исправили это
- У нас также были проблемы с исключениями, из-за которых appdomain restart, мы исправили это.
- В часы пик я смотрю на счетчики производительности asp.net. Мы можем видеть поведение: у нас 600 текущих подключений с 500 подключениями в очереди.
- В часы пик загрузка ЦП составляет около 40% (что заставляет меня думать, что он не привязан к ЦП)
- Физическая память используется примерно на 60%.
- В периоды пиковой нагрузки ЦП DatabaseServer составляет около 30% (что заставляет меня думать, что это не привязано к базе данных)
Я пришел к выводу, что что-то еще мешает серверу обрабатывать запросы быстрее. Возможные подозрения
- Тупики (! Syncblk дает только одну блокировку)
- Дисковый ввод-вывод (проверяется через sysinternals procsexplorer: 3,5 МБ / с)
- Сборка мусора (10 ~ 15% во время пиков)
- Сеть I / O (время соединения все еще мало)
Чтобы узнать, что делает процесс, я создал минидампы.
Мне удалось создать два дампа памяти с интервалом в 20 секунд. Это результат первого:
!threadpool
CPU utilization 6%
Worker Thread: Total: 95 Running: 72 Idle: 23 MaxLimit: 200 MinLimit: 100
Work Request in Queue: 1
--------------------------------------
Number of Timers: 64
и результат второго:
!threadpool
CPU utilization 9%
Worker Thread: Total: 111 Running: 111 Idle: 0 MaxLimit: 200 MinLimit: 100
Work Request in Queue: 1589
Как вы можете видеть, в очереди много запросов.
Вопрос 1: что значит 1589 запросов в очереди. Означает ли это, что что-то блокируется?
Список! Threadpool в основном содержит следующие записи: Неизвестная функция: 6a2aa293 Контекст: 01cd1558 AsyncTimerCallbackCompletion TimerInfo @ 023a2cb0
Если я углублюсь в AsyncTimerCallbackCompletion
!dumpheap -type TimerCallback
, то я посмотрю на объекты в TimerCallback, и большинство из них относятся к типам:
System.Web.SessionState.SessionStateModule
System.Web.Caching.CacheCommon
Вопрос 2: Имеет ли смысл то, что эти объекты имеют таймер, и так много? Должен ли я предотвратить это. И как?
Главный вопрос Я пропускаю какие-либо очевидные проблемы, почему я ставлю соединения в очередь и не загружаю ЦП на максимум?
Мне удалось сделать аварийный дамп во время пика. Анализируя это с помощью debugdiag, я получил следующее предупреждение:
Detected possible blocking or leaked critical section at webengine!g_AppDomainLock owned by thread 65 in Hang Dump.dmp
Impact of this lock
25.00% of threads blocked
(Threads 11 20 29 30 31 32 33 39 40 41 42 74 75 76 77 78 79 80 81 82 83)
The following functions are trying to enter this critical section
webengine!GetAppDomain+c9
The following module(s) are involved with this critical section
\\?\C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\webengine.dll from Microsoft Corporation
Быстрый поиск в Google не дал никаких результатов. Есть ли у кого-нибудь ключ к разгадке?