ASP.NET WebApp в Azure с использованием большого количества ЦП

У нас есть давно работающее веб-приложение ASP.NET в Azure, которое не имеет реальных конечных точек - оно служит единственной функциональной цели, в основном считывая данные базы данных и манипулируя ими, фактически это пакетная запланированная задача, запускаемая таймером каждые 30 секунд. Приложение работает нормально большую часть времени, но мы наблюдаем случайные проблемы, когда загрузка ЦП для приложения приближается к максимуму для AppServicePlan, мгновенно, а не постепенно, и перестает выполнять какие-либо дополнительные триггеры таймера, и мы не можем найти ничего явно в выполнение кода для его учета (никаких признаков взаимоблокировок и т. д., и все пути кода имеют try / catch, поэтому не должно быть необработанных исключений). Чаще всего мы видим ошибки при подключении к базе данных, но неясно, являются ли они причиной или симптомами.

Обратите внимание, что это единственный ресурс в рамках плана AppService. База данных SQL Azure находится в том же регионе и, хотя она используется другими приложениями, используется ими очень слабо, и они также не имеют проблем, обнаруженных проблемным приложением.

Такое ощущение, что это связано с инфраструктурой, но мы не смогли найти ничего, чтобы объяснить, что происходит, поэтому, если у кого-то есть предложения о том, где нам следует искать, они будут с благодарностью приняты. Мы включили базовую версию Application Insights (не SDK), но помимо наблюдения за скачком нагрузки на ЦП до потери ответа приложения, мало интересной информации, учитывая наши ограниченные знания о том, как наилучшим образом использовать Insights.


person ChrisB_WR    schedule 28.05.2020    source источник
comment
Что касается этой проблемы, у вас есть лучшее решение или идея? Это очень интересный вопрос, и я рад продолжать следить за развитием этого вопроса.   -  person Jason Pan    schedule 01.06.2020
comment
@ Джейсон, у меня сейчас нет больше ничего по этому поводу - мы рассмотрели возможность исчерпания возможностей обработки, но, насколько мы можем судить, мы не достигаем никаких ограничений   -  person ChrisB_WR    schedule 01.06.2020
comment
Я предлагаю вам поднять заявку в службу поддержки на лазурном портале, потому что мы не можем получить дополнительную информацию из наших приложений.   -  person Jason Pan    schedule 01.06.2020
comment
Использовали ли вы инструменты профилирования Azure или мониторинг ЦП, чтобы выгружать процесс при максимальной загрузке ЦП?   -  person MikeJ    schedule 05.06.2020
comment
@MarkJ большое спасибо за предложение - мы изучали мониторинг Kudu - это то, о чем вы говорите?   -  person ChrisB_WR    schedule 05.06.2020
comment
@ChrisB_WR Да, вы должны иметь возможность профилировать форму там. Это также может быть полезно в зависимости от вашей настройки ... azure.github.io/AppService/2019/10/07/ Этот ответ SO также может быть полезен - stackoverflow.com / questions / 49053245 /   -  person MikeJ    schedule 05.06.2020


Ответы (1)


Согласно вашему описанию, я подумал о двух способах устранения вашей проблемы. Прежде всего, вы можете отслеживать статус выполнения вашей программы с помощью кода и помещать журнал в начало и конец ваших запланированных пакетных задач, чтобы записывать статус каждого запуска. Если возможно, запишите информацию о запросе и ответе, а также начальную и конечную информацию. Это может полностью записать время и статус выполнения вашей задачи.

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

Поскольку вы не можете воспроизвести свою проблему, вы можете только догадываться о ее причине. Если вы по-прежнему не можете найти причину проблемы в двух вышеуказанных пунктах, измените свой таймер соответствующим образом и позвольте программе запускаться каждые 5 минут вместо 30 секунд.

person Jason Pan    schedule 30.05.2020
comment
Большое спасибо за предложения - мы уже пытались регистрировать статус, чтобы попытаться сузить круг сбоев, но, похоже, нет особой корреляции факторов, когда возникают сбои, что является одной из причин, по которой это больше похоже на инфраструктуру, чем на код. - person ChrisB_WR; 01.06.2020