Приложение Asp.net медленное, но CPU на 40% максимум

Question

У меня странная ситуация на производственном сервере. Соединение для asp.net будет поставлено в очередь, но процессор только на 40%. Кроме того, база данных работает нормально с 30% CPU.

Некоторые больше истории, как предложено в комментариях:

• В часы пик сайты получает около 20000 посетителей в час.
• Сайт представляет собой приложение ASP.NET WebForms с большим количеством AJAX/
сообщения
• Сайта использует много контента, созданные пользователей
• Мы измеряем производительность сайта с тестовой страницей, которая действительно попала в базу данных и веб-сервисы, используемые сайтом. Эта страница обслуживается в течение секунды при нормальной нагрузке. Определите приложение так медленно, когда запрос занимает более 4 секунд.
• Из измерений мы видим, что время соединения очень быстрое, но время обработки велико.
• Мы не можем точно определить медленный ответ на один запрос, сайт работает нормально в обычное время, но медленнее в часы пик
• У нас была проблема с тем, что сайт был связан с ЦП (он же работает на 100%), мы исправлено, что
• У нас также были проблемы с исключениями, вызванными перезапуском appdomain, мы исправили это сделать
• В часы пик я смотрю счетчики производительности asp.net. Мы можем видеть, что у нас есть 600 текущих соединений с 500 поставленными в очередь соединениями.
• В пиковые времена процессора составляет около 40% (что делает меня думать, что это не ЦП)
• физической памяти составляет около 60% используется
• В пиковые времена DatabaseServer процессора составляет около 30% (что заставляет меня думать, что это не привязано к базе данных)

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

• Тупики (syncblk дает только один замок!)
• Disk I/O (проверено с помощью Sysinternals procesexplorer: 3,5 Мбит/с)
• Вывоз мусора (10 ~ 15% во время пиков)
• Сетевой ввод-вывод (время подключения еще не установлено)

Чтобы узнать, что делает процесс, я создал для мини-пультов.

Мне удалось создать два MemoryDumps на расстоянии 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 содержит в основном эти записи: Unknown Функция: 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 не дает мне никаких результатов. У кого-то есть ключ?

Answer 1

Рабочие, обрабатывающие очередь, были настоящим разбойником. Вероятно, связано с веб-сайтом, вызывающим веб-службы на том же хосте. Таким образом, создается своего рода тупик.

Я изменил machine.config на к следующему:

<processModel 
     autoConfig="false" 
     maxWorkerThreads="100" 
     maxIoThreads="100" 
     minWorkerThreads="50" 
     minIoThreads="50" /> 

Стандартных этот processModel установлен в автонастройки = «истинный»

С новым конфигурацией веб-сервер обрабатывают запросы достаточно быстро, чтобы не получить в очереди.

Answer 2

Слишком много запросов в очереди ASP.NET разрушают производительность. Существует очень ограниченное количество потоков запросов.

Попробуйте освободить эти потоки, обработав медленные части ваших страниц асинхронно или сделайте что-нибудь еще, чтобы снизить время выполнения страницы.

Answer 3

Я с realworldcoder: IIS работает, если рабочие процессы обрабатывают входящие запросы. Если запросы сгруппированы, как кажется, это происходит, тогда производительность занимает нос.

Есть несколько возможных вещей, чтобы сделать/проверить.

1. Провести мониторинг активности на SQL Server. Вы хотите узнать, какие запросы занимают самые длинные и, в зависимости от результатов, вносить изменения, чтобы сократить время их выполнения. Длинные запросы могут привести к тому, что поток, на который выполняется страница, блокируется, уменьшая количество подключений, которые вы можете поддерживать.

2. Просмотрите количество запросов и время их выполнения для этих вызовов page/ajax. Я видел страницы с десятками ненужных запросов, которые выполняются для вызова Ajax просто потому, что .Net выполняет весь цикл страницы, даже если нужно выполнить только конкретный метод. Вы можете разделить эти вызовы на обычные страницы веб-обработчиков (.ashx), чтобы вы могли лучше контролировать то, что происходит.

3. Рассмотрите возможность увеличения числа рабочих процессов IIS для обработки входящих запросов. По умолчанию для нового пула приложений - 1 процесс с 20 threads. Обычно этого достаточно, чтобы обрабатывать тонны запросов; однако, если запросы блокируются из-за ожидания на сервере БД или какого-либо другого ресурса, это может привести к стеку трубопровода. Имейте в виду, что это может иметь либо положительное, либо отрицательное влияние как на производительность, так и на регулярное функционирование вашего приложения. Так что сделайте некоторое исследование, затем проверьте, испытайте, испытайте.

4. Рассмотрите возможность уменьшения или исключения использования сеанса.В любом случае, посмотрите на использование памяти, потенциально добавьте больше бара на ваш веб-сервер. Данные сеанса сериализуются и десериализуются для каждой загрузки страницы (включая вызовы ajax) независимо от того, используются ли данные или нет. в зависимости от того, что вы храните в сеансе, это может оказать серьезное негативное влияние на ваш сайт. Если вы не используете его, убедитесь, что он полностью отключен в вашем web.config. Обратите внимание, что эти проблемы только ухудшаются, если вы сохраняете сеанс веб-сервера, поскольку затем вы привязаны к скорости сети, когда страница извлекает и сохраняет ее.

5. Посмотрите на счетчики производительности сайтов вокруг компиляции JIT (Just-In-Time). Это должно быть почти не существует. Я видел, что сайты были на коленях огромными количествами JIT. После того, как эти страницы были перекодированы для его устранения, сайты снова начали летать.

6. Посмотрите на различные стратегии кэширования (я не рассматриваю сеанс реального кэширования). Возможно, есть вещи, которые вы постоянно запрашиваете, что вам действительно не нужно постоянно выходить из сервера БД. У моего друга есть сайт, где они кэшируют целые веб-страницы в виде физических файлов для динамического контента, включая их группы обсуждения. Это значительно увеличило их производительность; но это важное архитектурное изменение.

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

Answer 4

Был ли кто-нибудь, кто мог бы подтвердить, что это сработало для них? Я нашел этот ответ через Интернет, и есть нулевые подтверждения, что опубликованный ответ исправил эту проблему для них. С учетом сказанного я на самом деле не доверяю ему, так как ответ предоставляется постеру вопросов.

меня та же проблема, в последнее время:

Обнаруженные возможное блокирование или просочилась критическую секцию в webengine g_AppDomainLock принадлежащего нити 16 в w3wp.exe__DefaultAppPool__PID__3920__Date__04_26_2011__Time_10_40_42AM__109__IIS_COM + Повесьте dump.dmp Влияние этого замка

4.17% отключенных потоков (Темы 17) Следующие функции пытаются войти в этот критический раздел веб-сайта! GetAppDoma in + c9 Следующие модули связаны с этой критической секцией \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \.DLL из корпорации Microsoft

Это рекомендация опубликовано Microsoft для дальнейшего устранения:

Следующие поставщики были определены для прослеживания на основе корня причина анализа Microsoft Corporation Пожалуйста, следить с поставщиков, указанных выше. Рассмотрим следующий подход для определения основной причины для этой критической проблемы раздел :

1. Включить «блокировки проверки» в Application Verifier A. Download Application Verifier по следующему адресу: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=c4a25ab9-649d-4a1b-b4a7-c9d8b095df18&displaylang=en B. Включить «блокировки проверки» для этого процесса, выполнив следующую команду:

   Appverif.exe -enable locks -for w3wp.exe C. См следующий документ для получения дополнительной информации о проверяльщик приложений: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnappcom/html/appverifier.asp?frame=true

2. Используйте правило аварии DebugDiag для контроля за применение исключений

Answer 5

Я знаю, что это старая нить, но это один из первых Google хитов для людей с плохой работой сайта ASP.NET. Поэтому я вышлю несколько рекомендаций:

1) Асинхронное программирование решит основную причину. Пока вы звоните в веб-сервис, чтобы выполнять свою фактическую бизнес-логику, эти запросы-запросы просто сидят там, ожидая ответа. Вместо этого они могут использоваться для обслуживания другого входящего запроса. Это значительно сократит вашу очередь очереди, если не устранит ее полностью. Асинхронное программирование - это масштабируемость, а не индивидуальная производительность запросов. Это достигается довольно просто в .NET 4.5 с шаблоном Async/Await. ASP.NET внедряет потоки со скоростью 2 в минуту, поэтому, если вы не повторно используете эти существующие потоки, вы быстро закончите загрузку сайта, которую вы получаете. Кроме того, увеличение количества потоков - это небольшой успех; он занимает больше ОЗУ и времени, чтобы выделить эту ОЗУ. Простое увеличение размера пула потоков в machine.config не будет устранять основную проблему. Если вы не добавите больше процессоров, добавление большего количества потоков не поможет, так как это все еще нецелевое использование ресурсов, и вы также можете переключить себя на смерть, имея слишком много потоков и слишком мало CPU.

2) From a popular article on threading in IIS 7.5: Если ваше приложение ASP.NET использует веб-службы (WFC или ASMX) или System.Net для связи с базой данных через HTTP, вам может потребоваться увеличить connectionManagement/maxconnection. Для приложений ASP.NET это ограничение ограничено 12 * #CPUs функцией autoConfig. Это означает, что на quad-proc вы можете иметь не более 12 * 4 = 48 одновременных подключений к конечной точке IP. Поскольку это связано с autoConfig, самый простой способ увеличить максимальное соединение в приложении ASP.NET - это установить System.Net.ServicePointManager.DefaultConnectionLimit программным путем, например, из Application_Start. Установите значение для количества одновременных подключений System.Net, которые вы ожидаете от использования вашего приложения. Я установил это в Int32.MaxValue и не имел никаких побочных эффектов, поэтому вы можете попробовать это - это фактически значение по умолчанию, используемое в собственном стеке HTTP, WinHTTP. Если вы не можете программно установить System.Net.ServicePointManager.DefaultConnectionLimit, вам необходимо отключить autoConfig, но это также означает, что вам также необходимо установить maxWorkerThreads и maxIoThreads. Вам не нужно устанавливать minFreeThreads или minLocalRequestFreeThreads, если вы не используете классический/ISAPI-режим.

3) Вы должны действительно посмотреть на балансировку нагрузки, если вы получаете 20 тысяч уникальных посетителей в час. Если каждый пользователь выполнял 10-20 запросов AJAX в час, вы легко можете говорить о 1 миллисе или более вызовах веб-сервисов на ваш сервер. Выброс другого сервера снизит нагрузку на основной сервер. Объединяя это с async/await, и вы поставили себя в хорошую ситуацию, когда вы можете легко перетащить оборудование в проблему (масштабирование). Здесь много преимуществ, таких как избыточность оборудования, геолокация, а также производительность. Если вы пользуетесь облачным провайдером, таким как AWS или RackSpace, простое развертывание другой виртуальной машины с вашим приложением достаточно просто, чтобы это можно было сделать с вашего мобильного телефона. В настоящее время облачные вычисления слишком дешевы, чтобы даже иметь длину очереди вообще. Вы можете сделать это, чтобы обеспечить преимущества производительности даже до того, как вы перейдете к асинхронной модели программирования.

4) Масштабирование: добавление дополнительного оборудования на ваш сервер (ы) поможет, потому что оно обеспечивает лучшую стабильность при наличии дополнительных потоков. Больше потоков означает, что вам нужно больше процессоров и оперативной памяти. И даже после того, как вы получите асинхронный/ждущий под вашим поясом, вы все равно захотите точно настроить эти запросы веб-сервисов, если сможете. Это может означать добавление в слой кеширования или усиление системы базы данных. Вы НЕ хотите максимизировать процессор на одном сервере. Когда процессор достигнет 80%, ASP.NET перестанет впрыскивать больше потоков в систему. Не имеет значения, работает ли рабочий процесс на 0%, если общий объем использования ЦП системы, о котором сообщается диспетчером задач, достигает 80%, тогда вставка потока прекращается и запросы начинают ставиться в очередь. Странные вещи с сборкой мусора также происходят, когда он обнаруживает высокую загрузку процессора на сервере.