Disk Queue length of 30 in Azure App Service, that can't be right

We are having a battle with the Microsoft Azure support team. I hope the Faultserver.rumunity can chime in as the support team has messed us about before.

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

В рамках более крупной службы 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 рекомендует рассмотреть возможность увеличения показателя длины очереди диска до среднего значения не менее 50 в течение 10 минут.

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

Кто-нибудь хочет присоединиться?