SQL Server обнаружил, что запросы ввода-вывода занимают более 15 секунд

На производственном SQL Server у нас есть следующий конфиг:

3 сервера Dell PowerEdge R630, объединенные в группу доступности. Все 3 подключены к одному хранилищу Dell SAN, которое представляет собой массив RAID.

Время от времени на PRIMARY мы видим сообщения, подобные приведенным ниже:

SQL Server обнаружил 11 вхождений запросов ввода-вывода, выполнение которых занимало более 15 секунд в файле [F: \ Data \ MyDatabase.mdf] в идентификаторе базы данных 8. Дескриптор
файла ОС - 0x0000000000001FBC.
Смещение последнего длинного ввода-вывода: 0x000004295d0000.
Продолжительность длительного ввода-вывода составляет: 37397 мс.

Мы новичок в устранении неполадок производительности

Каковы наиболее распространенные способы или рекомендации для устранения этой конкретной проблемы, связанной с хранением? Какие счетчики производительности, инструменты, мониторы, приложения и т. Д. Необходимо использовать, чтобы определить причину таких сообщений? Может быть, есть какие-то расширенные события, которые могут помочь, или какой-то аудит / регистрация?

У нас похожая настройка, и недавно мы встретили эти сообщения в журналах. Мы используем DELL Compellent SAN. Вот несколько вещей, которые нужно проверить при получении этих сообщений, которые помогли нам найти решение

• Просмотрите счетчики производительности Windows для дисков, на которые указывают предупреждающие сообщения, а именно:
  • Диск средний Время Читать
  • Диск средний время записи
  • Дисковое считывание байт / сек
  • Запись на диск байт / сек
  • Передачи дисков / сек
  • Avg. длина очереди диска
• Выше средние. Если у вас есть много файлов базы данных на одном диске, эти средние значения могут исказить результат и замаскировать узкое место для определенных файлов базы данных. Проверьте этот запрос от Пола С. Рэндала, который возвращает среднюю задержку для каждого файла из dmv sys.dm_io_virtual_file_stats. В нашем случае средняя задержка была приемлемой, но под обложками у нас было много файлов со средней задержкой> 200 мс.
• Проверьте время. Есть ли какая-то картина? Это происходит чаще в определенное время ночью? Если это так, проверьте, выполняются ли какие-либо задания по обслуживанию в это время или какие-либо запланированные действия, которые могут увеличить активность диска и выявить узкое место в вашей подсистеме ввода-вывода.
• Проверьте окно просмотра событий Windows на наличие ошибок. Если ваш коммутатор или SAN перегружены или не настроены должным образом для вашего приложения, вы можете найти некоторые сообщения в этом журнале, и будет полезно передать эту информацию вашему администратору SAN. В нашем случае мы часто получали ошибки соединения iSCSI в течение дня, намекая на проблему.
• Просмотрите свой код SQL Server. Когда вы получаете эти сообщения, вы не должны сразу думать, что это проблема подсистемы ввода-вывода, и передавать ее своему администратору SAN. Вы должны внести свой вклад и просмотреть базу данных. Есть ли у вас действительно плохие запросы, часто выполняющиеся через тонны данных? Плохая индексация? Чрезмерный журнал транзакций пишет? Вы можете использовать некоторые запросы с открытым исходным кодом для проверки работоспособности вашей базы данных, например, для проверки того, как выглядит ваш план запросов, sp_blitzCache
• Не игнорируйте это. Сегодня вы можете получать их несколько раз в день ... затем несколько месяцев спустя, когда ваша рабочая нагрузка увеличивается, и вы забыли следить за ними, они начинают увеличиваться. Получение большого количества этих сообщений может помешать SQL Server получить доступ к определенному файлу, и если это tempdb , это нехорошо. В нашем случае все стало так плохо, что SQL Server отключился.

Нашим решением было обновление нашего коммутатора до коммутатора SAN. Да, это все аспекты SQL Server. То, что заставило нас узнать, что это был переключатель, - это то, что мы ежедневно получали около 1500 ошибок отключения iSCSI pdu в средстве просмотра событий приложений Windows на SQL Server. Это побудило наших администраторов SAN провести расследование в отношении коммутатора.

Сразу после обновления ошибки iSCSI исчезли, и средняя задержка снизилась до 50 мс для всех файлов, что коррелировало с улучшением производительности в приложении. Имея в виду эти моменты, надеюсь, вы сможете найти свое решение.

Это гораздо реже проблема с диском, и гораздо чаще проблема с сетью. Вы знаете, N в SAN?

Если вы пойдете в свою команду SAN и начнете говорить о медленных дисках, они покажут вам причудливый график с задержкой 0 миллисекунд, а затем укажут на вас степлер.

Вместо этого спросите их о сетевом пути к SAN. Получите скорости, если они многопоточны и т. Д. Получите от них числа о скоростях, которые вы должны видеть. Спросите, есть ли у них контрольные показатели, когда серверы были установлены.

Затем вы можете использовать Crystal Disk Mark или diskpd для проверки этих скоростей. Если они не выстраиваются, опять же, скорее всего, это сеть.

Вам также следует искать в журнале ошибок сообщения, содержащие «FlushCache» и «насыщенность», поскольку они также могут быть признаками конкуренции в сети.

Одна вещь, которую вы можете сделать, чтобы избежать таких вещей, как администратор БД, - убедиться, что ваше обслуживание и любые другие задачи с большими объемами данных (например, ETL) не выполняются одновременно. Это определенно может оказать большое давление на сети хранения данных.

Вы также можете проверить ответы здесь для получения дополнительных предложений: медленная контрольная точка и 15-секундные предупреждения ввода-вывода на флэш-памяти

Я написал в блоге о похожей теме здесь: с сервера на SAN

Зачем хранить данные в сети SAN? В чем смысл? Вся производительность базы данных связана с дисковым вводом-выводом, и вы используете 3 сервера с одним устройством для ввода-вывода за ними. Это не имеет смысла ... и, к сожалению, так часто.

Я провожу свою жизнь, сталкиваясь с плохо спроектированными аппаратными платформами, где люди просто пытаются спроектировать крупномасштабный компьютер. Вся мощность процессора здесь, все диски там ... надеюсь, что нет такой вещи, как удаленное ОЗУ. И самое печальное, что они компенсируют неэффективность этой конструкции огромными серверами, которые стоят в десять раз дороже, чем должны. Я видел 400 тыс. Долларов ниже, чем ноутбук за 1 тыс. Долларов.

Программное обеспечение SQL-сервера - это очень продвинутая часть программного обеспечения, разработанная для использования любых аппаратных средств, ядер ЦП, кеш-памяти ЦП, TLB, ОЗУ, контроллеров дисков, кеша жестких дисков ... Они почти включают в себя всю логику файловой системы. Они разработаны на обычном компьютере и протестированы на высокопроизводительных системах. Поэтому SQL-сервер должен иметь свои собственные диски. Установка их в SAN - это как «эмуляция» компьютера, вы теряете все оптимизации производительности. SAN предназначены для хранения резервных копий, неизменяемых файлов и файлов, к которым вы просто добавляете данные (журналы).

Администраторы центров обработки данных, как правило, помещают все, что могут, в сети SAN, потому что таким образом они могут управлять только одним пулом хранилища, это проще, чем забота о хранилище на каждом сервере. Это выбор «Я не хочу выполнять свою работу», и он очень плохой, потому что тогда им приходится иметь дело с проблемами производительности, и от этого страдают все компании. Просто установите программное обеспечение на оборудование, для которого оно предназначено. Будь проще. Забота о пропускной способности ввода / вывода, издержках переключения кеша и контекста, дрожании ресурсов (происходит, когда ресурс используется совместно). Вы в конечном итоге будете поддерживать 1/10 устройств с одинаковой исходной мощностью, избавлять свою операционную команду от головной боли, повышать производительность, которая делает ваших конечных пользователей счастливыми и более производительными, сделает вашу компанию лучшим местом для работы, и сэкономить много энергии (планета поблагодарит вас).

В комментариях вы сказали, что рассматриваете возможность установки SSD на свой сервер. Вы не узнаете настройки с выделенными твердотельными накопителями, по сравнению с SAN вы получите 500-кратное улучшение даже при наличии файлов данных и журналов транзакций на одном диске. Современный SQL Server будет иметь быстрый отдельный SSD для данных и журнала транзакций на разных каналах аппаратных контроллеров (большинство материнских плат сервера имеют несколько). Но по сравнению с вашими текущими настройками мы говорим о научной фантастике. Просто попробуйте SSD.

Хорошо, для всех, кто заинтересован,

Мы решили проблему в вопросе пару месяцев назад, просто установив напрямую подключенные SSD-диски на каждый из 3 серверов и переместив данные базы данных и файлы журналов из SAN на эти SSD-диски.

Вот краткое изложение того, что я сделал, чтобы исследовать эту проблему (используя рекомендации из всех публикаций этого вопроса), прежде чем мы решили установить SSD-накопители:

1) начал сбор счетчиков PerfMon для следующих дисков на всех 3 серверах:

Disk F:логический диск на основе SAN, содержит файлы данных MDF
Disk I:логический диск на основе SAN, содержит файлы журнала LDF
Disk T: ; напрямую подключается SSD, выделенный исключительно для tempDB

На рисунке ниже приведены средние значения, собранные за 2 недели

Disk I: (LDF)имеет такой маленький ввод-вывод, и задержка очень мала, поэтому диск I: можно игнорировать.
Вы можете видеть, что Disk T: (TempDB)ввод-вывод больше, чемDisk F: (MDF) , и в то же время имеет намного лучшую задержку - 0 мс

Очевидно, что-то не так с диском F: где находятся файлы данных, он имеет высокую задержку и Avg Disk Write Queue, несмотря на низкий IO

2) Проверено время задержки для отдельных баз данных, используя запрос с этого сайта

https://www.brentozar.com/blitz/slow-storage-reads-writes/

Немногие активные базы данных на основном сервере имели задержку чтения 150-250 мс и задержку записи 150-450 мс.
Что интересно, файлы баз данных master и msdb имели задержку чтения до 90 мс, что подозрительно, учитывая небольшой размер их данных и низкий уровень ввода-вывода - еще один признак того, что что-то не так с SAN

3) Не было конкретных сроков

Во время которых появлялись сообщения «SQL Server обнаружил ...».
Когда эти сообщения были зарегистрированы, не было никакого обслуживания или тяжелого ETL на диске.

4) Windows Event Viewer

Не отображались никакие другие записи, которые бы указывали на проблему, кроме «SQL Server обнаружил вхождения ...»

5) Началась проверка топ-10 запросов

От sp_BlitzCache (cpu, reads и т. Д.) И omptimizing, где это возможно.
Никаких тяжелых IO-запросов, которые могли бы сжать тонны данных и сильно повлиять на хранилище, хотя
индексирование в базах данных в порядке, я поддерживаю его

6) У нас нет команды SAN

У нас есть только 1 системный администратор, который помогает в некоторых случаях
Сетевой путь к SAN - он является многопоточным, у каждого из 3 серверов есть 2 сетевых кабеля, ведущих к коммутаторам, а затем к SAN, и он должен составлять 1 гигабайт / сек.

7) не было результатов CrystalDiskMark

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

8) Настройте сеанс расширенных событий на событие контрольной точки для рассматриваемой базы данных

Сессия XE помогла обнаружить, что во время сообщений «SQL Server обнаружил события ...» контрольная точка происходила очень медленно (до 90 секунд)

9) Журнал ошибок SQL Server

Содержит записи FlushCache «Saturation».
Они должны отображаться, когда время контрольной точки для данной базы данных превышает настройки интервала восстановления.

Детали показали, что объем данных, которые пытается очистить контрольная точка, невелик и занимает много времени, а общая скорость составляет около 0,25 МБ / с ... странно

10) Наконец, на этом рисунке показана диаграмма устранения неполадок хранилища:

Кажется, у нас просто есть «Аппаратная проблема: - Работайте с системным администратором / поставщиком оборудования, чтобы исправить любую неправильную конфигурацию SAN, старых / неисправных драйверов, контроллеров, прошивки и т. Д.»

В другом вопросе «Медленная контрольная точка ...» Медленная контрольная точка и 15-секундные предупреждения ввода-вывода на флэш-накопителе У Шона был очень хороший список того, какие элементы необходимо проверять на аппаратном и программном уровне для устранения неполадок.

Наш системный администратор не смог проверить все вещи из списка, поэтому мы просто решили добавить некоторые аппаратные средства в этом вопросе - это было совсем не дорого

Разрешение:

Мы заказали SSD-накопители емкостью 1 ТБ и установили их непосредственно на серверы.

Поскольку у нас есть группы доступности, перенесены файлы данных БД из SAN в SSD на вторичных репликах, затем выполнен отказоустойчивый и перенесены файлы на прежние первичные. Это позволило за минимальное общее время простоя - менее 1 минуты

Теперь у каждого сервера есть локальная копия данных БД, и полное резервное копирование / diff / log выполняется в упомянутую SAN.
Больше нет сообщений «SQL Server встретился с возникновением ...» в журналах средства просмотра событий Windows, а также выполняются операции резервного копирования, проверки целостности, индекс перестроен, запросы и т. д. значительно увеличилась

Насколько улучшилась производительность с точки зрения задержки ввода-вывода после того, как мы перенесли файлы БД на SSD?

Чтобы оценить влияние, использовалась производительность. Системный журнал Windows Performance Monitor регистрирует за 2 недели до миграции и через 4 недели после миграции:

Также ниже приведено сравнение статистики задержек на уровне БД (используется статистика захваченных виртуальных файлов SQL Server до и после миграции)

Резюме

Миграция с SAN на напрямую подключенные локальные SSD того стоила
Она оказала большое влияние на задержку хранилища и улучшилась в среднем более чем на 90% (особенно операции WRITE), и у нас больше нет 20-50-секундных пиков при вводе-выводе

Переход на локальный SSD решил не только проблемы с производительностью хранилища, но и безопасность данных, о которой я беспокоился (в случае сбоя SAN все 3 сервера теряют свои данные одновременно)