У меня есть среда, в которой работает SQL Server на платформе Windows VMWare с использованием SAN с SSD-дисками, настроенными в RAID 6, и Veeam для резервного копирования сервера и LiteSpeed для резервного копирования SQL Server.
За последний год у меня несколько раз возникала проблема: иногда база данных работала очень медленно, средняя длина очереди на диск была высокой, а скорость передачи данных на диск в байтах/сек была намного ниже, чем должна была.
Вот Performance Monitor на сервере базы данных. Когда возникает эта проблема, Avg. Disk Queue Length всегда находится в диапазоне нескольких сотен, а Disk Bytes/sec остается около 5-15 МБ/сек. Во время нормальной работы (когда эта проблема не возникает), Disk Bytes/sec достигает 900 МБ/сек или около того.
За время, прошедшее с момента возникновения этой проблемы, я заменил оборудование SAN, включая коммутаторы. Но проблема осталась на новом оборудовании.
Моя теория заключается в том, что это не проблема SQL Server, потому что если бы проблема была в том, что SQL Server перегружал дисковый ввод-вывод, я бы увидел гораздо более высокий Disk Bytes/sec. Но когда бы ни возникала эта проблема, Disk Bytes/sec всегда очень низок.
Я думал, что это может быть связано с программным обеспечением резервного копирования, работающим либо на сервере базы данных, либо на другом сервере, использующем ту же VMWare/SAN, но ни резервное копирование сервера, ни резервное копирование SQL Server, похоже, не выполняются во время возникновения этой проблемы.
Последняя мысль, что это проблема с VMWare, но я связался с ними, и пока они не смогли помочь.
Перезагрузка сервера базы данных решает проблему. Иногда проблема повторяется в течение дня, а иногда проблема не повторяется месяцами. Всякий раз, когда возникает проблема, я не знаю ничего, кроме обычной рабочей нагрузки, выполняемой в базе данных.
Что может быть причиной этой проблемы, при которой пропускная способность диска падает примерно до 1% от того, на что она должна быть способна?
решение1
Жесткие диски становятся медленнее, чем длиннее их очередь работы, и наоборот — существует очень ограниченное число IOPS, которые вы можете им предоставить (примерно 40-200, в зависимости от класса и RPM). Любое увеличение спроса сверх этой точки еще больше снижает их производительность.
Создание массива HDD увеличивает общее количество возможных операций чтения IOPS по всему массиву, но обычно меньше, чем простое суммирование их индивидуальных операций IOPS. IOPS записи более сложны и сильно зависят от уровня RAID, кэширования и т. д.
Для всего, что выходит за эти рамки, требуются твердотельные накопители и соответствующие контроллеры.
решение2
Поскольку вы уже используете SSD, я бы предположил, что проблема может быть похожа на ту, что была у меня, с TRIM, который не обрабатывается должным образом в SSD. Стирание блока данных на SSD не происходит мгновенно, подготовка блока для повторного использования может быть медленным процессом и может быть причиной замедления — если ваши свободные и подготовленные блоки исчерпаны, массив может существенно замедлиться по мере подготовки новых блоков. Убедитесь, что ваш SAN знает, что это SSD, и что у них включен фоновый TRIM.