Некоторые запросы на IIS зависают на несколько минут и заканчиваются потерей соединения - PullRequest
Новая
       8

Некоторые запросы на IIS зависают на несколько минут и заканчиваются потерей соединения

0 голосов
/ 05 января 2020

У меня неловкая проблема с IIS 10.0 на Windows Server 2016 и ASP. Net 4.5.2 и MVC 5.2.7.

Иногда некоторые запросы не принимаются ответ и запустить в течение минут, может быть, 10 или около того, прежде чем закончить в потерянное соединение (PR_CONNECT_RESET_ERROR в Firefox на Windows, NSURLDomainError в Firefox на iOS). В основном это POST-запросы. Когда эта проблема возникает, другие запросы GET получат быстрый ответ и правильный результат. Обычно POST-запрос не занимает много времени для обработки, как правило, менее 3 секунд.

Повторная обработка соответствующего рабочего процесса устранит проблему go на несколько часов или дней.

Когда сегодня осматривал веб-сервер, когда возникла проблема, я увидел небольшое использование процессора, менее 10%, память 56%, рабочий процесс занимал скромные 615 МБ. Я не видел ни регистрации в журнале этих запросов W3 C, ни в своих пользовательских журналах приложений.

Я добавил соответствие Web-Request-Monitor Как я вижу выполняющийся в настоящее время веб-запрос на IIS 8 , но при этом рабочий процесс, вероятно, был переработан, так как проблема в настоящее время не возникает.

Между inte rnet и моим веб-сайтом существует обратный прокси-сервер и менеджер доступа. сервер. Я полагаю, что они могут иметь какое-то отношение к этой проблеме, но это, безусловно, связано с IIS, поскольку переработка помогает.

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

Какие могут быть дальнейшие шаги для дальнейшего изучения этой проблемы?

Ответы [ 2 ]

0 голосов
/ 15 января 2020

Я нашел вероятную причину. Я сообщу о шагах, предпринятых для изучения проблемы.

  1. I активировал функцию Рабочие процессы в IIS .
  2. Когда после пары дней ожидания проблема началась снова, я обнаружил длинные запущенные запросы. Все они имели состояние ExecuteRequestHandler и имя модуля ManagedPipelineHandler . У них было Время истекло из сотен секунд.
  3. Я также активировал Трассировка невыполненных запросов с правилом для длительных запросов с Время получения 1 минуты.
  4. Через пару дней я начал получать отчеты о неудачных запросах. Все неудавшиеся запросы имеют событие GENERAL_SET_RESPONSE_HEADER в качестве последнего события.
  5. Я добавил дополнительные события ведения журнала отладки для каждого запроса. При отладке в моей среде разработки в какой-то момент я начал видеть поведение зависания там, в одном из новых операторов ведения журнала (!). Приложение использует log 4net.

  6. Я захватил трассировку стека:

    log4net.dll!log4net.Appender.AppenderSkeleton.DoAppend(log4net.Core.LoggingEvent loggingEvent) log4net.dll!log4net.Util.AppenderAttachedImpl.AppendLoopOnAppenders(log4net.Core.LoggingEvent loggingEvent) log4net.dll!log4net.Repository.Hierarchy.Logger.CallAppenders(log4net.Core.LoggingEvent loggingEvent) log4net.dll!log4net.Repository.Hierarchy.Logger.Log(System.Type callerStackBoundaryDeclaringType, log4net.Core.Level level, object message, System.Exception exception) log4net.dll!log4net.Core.LogImpl.DebugFormat(string format, object arg0)

В методе DoAppend используется lock(this), что вполне может привести к зависанию.

Я также обнаружил, что для параметра конфигурации log 4net .Internal.Debug установлено значение true , чего я не хочу при нормальных обстоятельствах, и это может быть связано. Я не пытался понять код log 4net, но я помню, что ведение журнала изначально не работало в среде принятия, поэтому в таком случае для настройки вполне могло быть задано значение true, что привело к запуску проблемы.

Еще одним признаком того, что это происходит с журналом 4net, является то, что, когда проблема возникла в последний раз, я понял, что регистрация уровня стандарта ведется только в некоторых запросах POST. Я нашел POST-запрос, который не регистрирует и запросы к нему, где обрабатываются нормально, в то время как другие POST-запросы все еще зависали.

На данный момент я установил log 4net .Internal.Debug в false и будет ждать, чтобы увидеть, что произойдет.

0 голосов
/ 06 января 2020

IIS recycle исправить эту проблему не означает, что это проблема IIS, потому что все asp. net приложения выполняются в. net времени выполнения, если не доказано, что запрос завис в модуле IIS.

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

Если все запросы зависают. net время выполнения. Тогда вам, возможно, придется захватить дамп зависания и сделать глубокий анализ через расширение WINDGB и mex. Он расскажет нам, что там происходит.

...