Длина очереди диска сервера высокая, но байты в секунду на диске меньше, чем он способен обрабатывать.

Вопрос или проблема

У меня есть среда, работающая на SQL Server в Windows на платформе VMWare с использованием SAN с SSD, настроенными в RAID 6, и Veeam для резервного копирования серверов и LiteSpeed для резервного копирования SQL Server.

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

Вот монитор производительности на сервере базы данных. Когда возникает эта проблема, средняя длина очереди диска всегда составляет несколько сотен, а число байт диска в секунду держится в пределах 5-15 МБ/сек. В обычном режиме работы (когда этой проблемы нет) число байт диска в секунду достигает порядка 900 МБ/сек.

С момента начала этой проблемы я заменил оборудование SAN, включая коммутаторы. Но проблема продолжается на новом оборудовании.

Моя теория состояла в том, что это не проблема SQL Server, потому что если бы проблема была в том, что SQL Server насыщает диск I/O, я бы видел гораздо больше байт диска в секунду. Но когда возникает эта проблема, число байт диска в секунду всегда очень низкое.

Я думал, может быть, это программное обеспечение для резервного копирования — либо работающее на сервере базы данных, либо работающее на другом сервере, который использует ту же VMWare/SAN — но ни резервные копии сервера, ни резервные копии SQL Server, похоже, не выполняются, пока происходит эта проблема.

Моя последняя мысль — это проблема с VMWare, но я связался с ними, и пока они не смогли помочь.

Проблема, кажется, ограничена SQL Server. Я пробовал перемещать большие файлы, пока SQL Server имеет эту проблему, и диск активности действительно подскакивает до скорости, которую я бы ожидал. Я пытался остановить и перезапустить SQL Server в SSMS, но это не решает проблему.

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

Что может вызывать эту проблему, из-за которой пропускная способность диска замедляется до примерно 1% от того, на что она должна быть способна?

HDD становятся медленнее, чем длиннее становится их очередь работы, и наоборот – существует очень ограниченное количество IOPS, которое можно использовать (примерно 40-200, в зависимости от класса и RPM). Любое увеличение нагрузки сверх этой точки дополнительно снижает их производительность.

Создание массива HDD увеличивает общее количество возможных операций чтения IOPS по всему массиву, но обычно меньше, чем просто сумма их индивидуальных IOPS. Записываемые IOPS более сложны и зависят сильно от уровня RAID, кэширования и т. д.

Все, что выходит за рамки этого, требует SSD и подходящих контроллеров.

Поскольку вы уже используете SSD, я бы предположил, что проблема может быть аналогична той, с которой я сталкивался, с TRIM, который неправильно обрабатывается на SSD. Удаление блока данных на SSD не является мгновенным, подготовка блока для повторного использования может быть медленным процессом и может быть причиной замедления – если ваши свободные и подготовленные блоки израсходованы, массив может значительно замедлиться по мере подготовки новых блоков. Убедитесь, что ваш SAN знает, что это SSD, и что у них включен фоновый TRIM.

Ответ или решение

Проблема, описанная выше, связана с тем, что среда SQL Server на платформе VMware, использующей SAN с SSD в RAID 6, испытывает замедление работы базы данных. Основные индикаторы – высокий средний уровень очереди диска (Avg. Disk Queue Length) и низкая скорость передачи данных (Disk Bytes/sec), даже несмотря на то, что мощность системы это позволяет.

Теория

Средняя длина очереди дисков (Disk Queue Length) указывает на количество операций ввода-вывода (I/O) на дисках, ожидающих выполнения. Высокие значения этой метрики могут свидетельствовать о том, что запрашиваемые операции ввода-вывода превышают возможности системы обработки. При этом показатель Disk Bytes/sec позволяет понять, использует ли система всю доступную пропускную способность диска.

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

Пример

Рассмотрим конкретный сценарий, когда используется SSD масив с RAID 6. Хотя чаще всего RAID 6 обеспечивает хорошую производительность чтения, скорость записи может быть значительно снижена из-за необходимости обработки избыточности данных. Это может проявляться особенно остро при высокой нагрузке на запись или недостаточном управлении внутренними процессами SSD, такими как TRIM.

TRIM – это команда, позволяющая SSD корректно удалять файлы и управлять свободным пространством, предотвращая его замедление при длительной эксплуатации. Если SAN-система или контроллер не поддерживает команду TRIM должным образом, производительность дисков может снизиться вследствие накопления неиспользуемого пространства для записи.

Применение

Для решения проблемы, следует рассмотреть и проверить следующие аспекты:

1. Оптимизация конфигурации SAN: Убедитесь, что SAN-система правильно распознает SSD и поддерживает технологию TRIM. Проверьте настройки SAN, чтобы убедиться, что активирована фоновая очистка и оптимизация свободного пространства.

2. Анализ VMware: Изучите возможное влияние окружения VMware на производительность ввода-вывода. Иногда из-за конфигурационных ошибок или недоработок в управлении ресурсами, виртуальные машины могут не эффективно использовать доступные ресурсы. Попробуйте обновить драйвера VMware или протестировать на другой версии гипервизора.

3. Изучение SQL Server: Проверьте конфигурации SQL Server. Не установлены ли какие-либо процессы или задачи, вызывающие блокировки или вызывающие значительные задержки? Возможно, необходимо оптимизировать запросы или схемы базы данных.

4. Мониторинг дисковой активности: Используйте специализированные инструменты мониторинга, чтобы понять, какие именно операции вызывают нагнетание очереди диска. Это могут быть фоновые задачи, выполняющие множество мелких операций ввода-вывода, такие как антивирусное сканирование или аналитику приложения.

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

6. Согласование работы с Veeam и LiteSpeed: Проверьте расписание и механизмы взаимодействия баз данных и программного обеспечения для резервного копирования. Повторная калибровка этих процессов может помочь избежать одновременного выполнения интенсивных задач.

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