ASP. NET WebApp в Azure с использованием большого количества ЦП - PullRequest
7 голосов
/ 28 мая 2020

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

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

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

1 Ответ

0 голосов
/ 30 мая 2020

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

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

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

...