Недавно мы столкнулись с ситуацией, когда ЦП нашего плана обслуживания приложений находился на уровне 100% в течение значительного периода времени (8-10 часов). Наша служба приложений использовала план B2 (разработка), масштабируемый сервер 2, SQL (250 ГБ) 20 DTU.
Наше приложение, размещенное в плане службы приложений, завершилось с ошибкой «Предел запроса для базы данных равный 90 и был достигнут ", поскольку он получает много запросов в течение этого времени.
Чтобы быстро решить проблему, мы увеличили наш план обслуживания приложений до P3 (производство), увеличив масштаб до 6, От DTU до 1600, после этого наше приложение снова заработало, но некоторые функции не работали, поскольку одна из служб приложений постоянно работала на 100% ЦП. Мы пытались увеличить масштаб до 16, оставаясь прежним, после нескольких часов, когда количество запросов значительно уменьшилось. число процессоров по-прежнему было на уровне 100%.
Мы запустили профилировщик kudu в течение 3-4 минут и проверили диагностику, была запись для структуры среды, которая потребляла больше всего процессоров около 90%, но мы были нигде в нашем коде приложения не используется структура сущностей.
Дальнейшая отладка приводит к состоянию сеанса, используемому в приложении (которое использует Entity Framework за сценой).
Ниже приведен файл web.config для установки состояния сеанса
<sessionState mode="Custom" customProvider="DefaultSessionProvider" timeout="30">
<providers>
<clear />
<add name="DefaultSessionProvider" type="System.Web.Providers.DefaultSessionStateProvider, System.Web.Providers, Version=2.0.0.0, Culture=neutral, PublicKeyToken=35bg3856ae324e35" connectionStringName="azuredbconstring" />
</providers>
</sessionState>
как часть быстрого В качестве разрешения мы изменили режим состояния сеанса на inpro c, и внезапно все стало нормально, процессор был на уровне 0-1%.
Мы снова изменили план обслуживания приложения на B2, уменьшив масштаб до 2, DTU базы данных на 20, все еще хорошо, процессор только на 0-1%.
Затем мы заметили, что в таблице сессий было 30000 записей (размер отдельных записей почти 14 КБ), все они были созданы в тот же день, ни одна из записи были удалены после истечения срока действия.
Может кто-нибудь объяснить, почему автоматическая очистка не сработала?
Мы проверили понимание производительности (azure => база данных => обзор производительности => запрос представление о производительности) и наблюдалось ниже. Запрос потреблял больше всего ресурсов
SELECT
[Extent1].[SessionId] AS [SessionId],
[Extent1].[Created] AS [Created],
[Extent1].[Expires] AS [Expires],
[Extent1].[LockDate] AS [LockDate],
[Extent1].[LockCookie] AS [LockCookie],
[Extent1].[Locked] AS [Locked],
[Extent1].[SessionItem] AS [SessionItem],
[Extent1].[Flags] AS [Flags],
[Extent1].[Timeout] AS [Timeout]
FROM [dbo].[Sessions] AS [Extent1]
WHERE [Extent1].[Expires] < (SysUtcDateTime())
Мы предполагаем, что это запрос, используемый автоматической очисткой для выбора и удаления.
Мы воспроизводим Изменив сценарий, скопировав данные таблицы сеансов в тестовой среде, ЦП перешел на 100% за несколько минут, данные также не были удалены из тестовой среды.
Как работает автоматическая очистка в среде azure?