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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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