Приложение IIS ASP.net неожиданно вызывает запросы

Question

У нас есть приложение asp.net, работающее на IIS 8.5, когда есть высокий трафик, с перерывами примерно на 1 минуту, «очередь запросов» начинает расти, а время процессора падает, смотрите монитор производительности график:

самое странное в том, что нет никакого перезапуска приложения, 503 или рециркуляционный IIS происходит, так что это может быть? Что вдруг заставляет IIS зависеть от запросов на некоторое время? Помимо графика вы можете видеть, что память Windows выглядит нормально и стабильно.

Вот некоторые среды конфигурации: APP Pool Длина очереди: 10000 (нет 503, так что я не думаю, что это может быть это)

Asp.net конфигурации:

<system.web> 
    <applicationPool maxConcurrentRequestsPerCPU="999999" /> 
</system.web> 

machine.config:

<processModel autoConfig="false" requestQueueLimit="250000"/> 

Мы настроили это так, потому что наше приложение использует много SignalR.

Приложение использует Azure SQL Server и Azure Redis, но это не проблема, поскольку другая виртуальная машина (с тем же APP) не показывает проблему в тот же момент.

Еще один совет: в той же VM у нас есть тот же APP, но в другом пуле приложений и в другом домене, который ведет себя одинаково.

Любая помощь будет оценена, это сводит меня с ума.

Спасибо!

Answer 1

Вы следовали рекомендациям по настройке параметров роста потока, которые предлагает Redis, см. here. Имели подобные проблемы.

Answer 2

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

1. посмотреть на ДТУ процент для сервера Azure SQL, если signalr операции не имеет ничего общего с базой данных. просто попробуйте пройти один уровень в шкале DTU для обработки всплеска. DTU
2. для приложения с сигналом с несколькими виртуальными машинами (при условии балансировки нагрузки), у вас есть центральный сервер signalr или каждый сервер, ведущий себя как сервер signalr?

Если вы можете установить NewRelic или аналогичный, это укажет на источник проблемы.

Надеюсь, что это поможет.

Answer 3

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

Если у вас есть Visual Studio Enterprise, то это даст вам хороший интерфейс для анализа дампа. Он покажет вам все потоки, выполняющие этот процесс, и то, что столбец был во время дампа памяти. Вероятно, вы найдете большую часть.NET-потоки имеют аналогичный callstack, который был бы наиболее вероятной причиной узкого места.

Если у вас нет Visual Studio Enterprise, то я думаю, что вы все равно можете открыть его с помощью WinDbg, но это инструмент CLI, и я не знаю команд, поэтому вам нужно будет найти его.

Answer 4

Добавь еще один столбец, содержащий сведения о твоем графике: Частные байты. Этот номер укажет вам количество байтов во всех управляемых кучах + количество неуправляемых байтов. Если это число продолжает расти, тогда у вас где-то есть утечка памяти. Убедитесь, что все одноразовые предметы удалены надлежащим образом, и предметы не сохранились до сбора G3. Во всяком случае, я бы начал там, и если это будет проблемой, я начну свое расследование и посмотрю, что происходит.