Дисковая очередь длиной 30 в Службе приложений Azure, это не может быть правильным

У нас идет битва со службой поддержки Microsoft Azure. Я надеюсь, что сообщество Serverfault сможет присоединиться к нам, поскольку команда поддержки раньше нас запутала.

Вот что происходит.

В рамках более крупной службы SaaS, которую мы размещаем в Azure, у нас есть интерфейсная служба приложений, которая принимает базовые HTTP-запросы, выполняет небольшую проверку, а затем передает базовую работу внутреннему серверу. Этот процесс не требует интенсивного использования ЦП, памяти или сети, и мы вообще не затрагиваем дисковую подсистему.

Ценовой уровень - «Базовый: 2 Средний», что более чем достаточно для той нагрузки, которую мы на него возлагаем. Диаграммы ЦП и памяти показывают, что система в основном находится в спящем режиме с использованием памяти около 36%.

Уделяя большое внимание в школе серверов, мы активно отслеживаем различные уровни общего решения, используя стандартные средства мониторинга Azure. Один из счетчиков, который мы отслеживаем, - это «Длина очереди диска», это один из очень немногих счетчиков, доступных в Службах приложений Azure, поэтому он должен быть важным.

Еще в школе серверов нам сказали, что длина дисковой очереди в идеале должна быть равна нулю, и если она постоянно превышает 1, вам нужно действовать вместе (есть некоторые исключения для определенных конфигураций RAID). За последние несколько лет все было хорошо, длина дисковой очереди была равна нулю в 99% случаев с периодическим увеличением до 5, когда Microsoft обслуживала систему.

Пару месяцев назад все начало меняться внезапно (не после того, как мы ввели изменения). Начались сообщения о дисковых очередях, и средняя длина очереди составляет 30 секунд.

Мы даем ему поработать несколько дней, чтобы увидеть, исчезнет ли проблема (на производительность это заметно не повлияет, по крайней мере, при текущей нагрузке). Поскольку проблема не исчезла, мы подумали, что, возможно, проблема в базовой системе, поэтому мы создали экземпляр новой службы приложений Azure и перешли на нее. Та же проблема.

Поэтому мы обратились в службу поддержки Azure. Естественно, они попросили нас провести несколько бессмысленных тестов в надежде, что мы уйдем (они попросили трассировку сети ... для проблемы с очередью на диске!). Мы не сдаемся так легко, поэтому мы запустили их бессмысленные тесты и в конце концов нам сказали просто установить предупреждение для длины очереди на 50 (более 10 минут).

Хотя у нас нет контроля над базовым оборудованием, инфраструктурой и конфигурацией системы, это звучит неправильно.

Их полный ответ выглядит следующим образом

Я обратился к нашей группе разработчиков продукта с информацией, собранной по этому делу.

Они исследовали проблемы, при которых предупреждение, указанное вами для длины очереди диска, срабатывает чаще, чем ожидалось.

Это предупреждение настроено на уведомление, если средняя длина очереди диска превысила 10 в течение 5 минут. Этот показатель представляет собой среднее количество запросов на чтение и запись, которые были поставлены в очередь для выбранного диска в течение интервала выборки. Для инфраструктуры службы приложений Azure эта метрика обсуждается в следующей ссылке документации: https://docs.microsoft.com/en-us/azure/app-service-web/web-sites-monitor

Значение 10 очень мало для любого типа развернутого приложения, поэтому вы можете видеть ложные срабатывания. Это означает, что предупреждение может срабатывать чаще, чем указано точное количество подключений.

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

Мы не обнаружили ни одного случая этого сканирования на наличие вредоносных программ, влияющего на доступность вашего сайта. Microsoft рекомендует рассмотреть возможность увеличения метрики Disk Queue Length со средним значением не менее 50 за 10 минут.

Мы считаем, что это значение должно позволить вам продолжать отслеживать работу вашего приложения с целью повышения производительности. Он также должен меньше зависеть от сканирования Anti-Malware или других подключений, которые мы запускаем в целях обслуживания.

Кто-нибудь хочет вмешаться?