Я разработчик и очень мало знаю о системах хранения. На работе я заметил медленную производительность больших запросов на одном из серверов SQL. Мне сказали, что база данных находится на волоконно-оптическом канале SAN MSA1500 (HP?) С 14 дисками COMPAQ BF3008B26C. Я сделал быстрый тест настройки HD, когда сервер практически не был загружен. Среднее чтение было около 60 МБ / с. Я мало что знаю о SAN, но эта скорость чтения кажется мне очень низкой. Тест локального чтения HD выше. Прежде чем я пойду к своим ИТ-специалистам с тем, что, по моему мнению, является огромной потенциальной ошибкой в настройке, я просто хотел узнать ваше мнение, ребята.
Обычные преступники:
Разделы диска Windows не выровнены с SAN. Это связано с тем, что в версиях Windows Server до 2008 года разделы запускаются в 64-м секторе.
Размер единицы распределения NTFS должен быть 64 КБ (рекомендуется).
Неоптимальный размер полосы SAN
Проверить выравнивание диска можно с помощью команды:
раздел wmic получить размер блока, начальное смещение, имя, индекс
Если начальное смещение равно 32256, раздел не выровнен.
Больше информации:
Рекомендации по выравниванию дисковых разделов для SQL Server
У меня есть MSA1500CS, и он постоянно уступает мне по производительности примерно с теми же показателями, что и вы. У меня диски SATA. Когда они были у меня в конфигурациях рейдов с четностью (RAID5 или 6), пропускная способность составляла около 60 МБ / с. Контроллеры там действительно недостаточно запитаны. С тех пор я перешел на RAID10, и пропускная способность значительно увеличилась, в основном потому, что я не использую почти столько ресурсов процессора контроллера для вычислений четности.
Кроме того, у этого устройства есть неприятная привычка отключать кэш записи при выполнении определенных функций массива. Такие вещи, как добавление диска в дисковый массив, изменение размера полосы на LUN или восстановление после неисправного диска. Когда это происходит, любые RAID LUN с контролем четности становятся очень чувствительными к записи. Выбрасывайте слишком много операций ввода-вывода для записи, и это начинает резко замедлять скорость записи на диски. Более быстрые диски могут помочь, но по большей части это проблема ресурсов ЦП контроллера.
Тем не менее, у вас есть диск SCSI, а не SATA. Это должно значительно улучшить производительность, хотя, опять же, RAID с контролем четности может не сильно улучшиться. Что могло бы улучшить производительность, так это использование на нем прошивки Active / Active и использование циклического алгоритма MPIO для распределения нагрузки ввода-вывода между обоими контроллерами. Последнее, что я проверял, это можно было сделать только в однородных средах хост-ОС (то есть во всей Windows или во всем Linux).
Это устройство разработано таким образом, что чувствительные к задержкам рабочие нагрузки («интерактивные» рабочие нагрузки на языке HP) предназначены для запуска в зеркальном наборе, а архивные рабочие нагрузки («ближние» рабочие нагрузки) - для RAID-массивов с контролем четности. Попытка использовать RAID с контролем четности в онлайн-роли возможна, пока ваше приложение допускает потенциально очень серьезную задержку. Мои не были, и это вызвало серьезные проблемы.
Сообщается, что линейка MSA2000 намного лучше справляется с этим.
MSA1500 не так быстры по стандартам SAN, но неправильно сконфигурированные SAN часто не справляются с нагрузками, такими как хранилища данных. Вполне вероятно, что это неправильно настроенная сеть SAN (возможно, размер полосы в массиве слишком мал). Также возможно, что SAN по своей сути медленная - не все SAN созданы равными.
Для нагрузки с большим объемом (а не для поиска), такой как хранилище данных, вы, вероятно, получите гораздо лучшую производительность от дисковых массивов с прямым подключением. В рабочей нагрузке с произвольным доступом, такой как транзакционное приложение, ограничения контроллера, как правило, маскируются действием механического поиска на диск. Проблемы с производительностью с большей вероятностью проявятся при потоковой нагрузке, например, при сканировании большой таблицы фактов.
Плохая структура диска, такая как размещение томов журналов на тех же дисках, что и загруженные рабочие нагрузки с произвольным доступом, также может непропорционально повлиять на производительность диска в SAN.
Чтобы понять, привязано ли что-то к диску, взгляните на статистику ожидания Page IO Latch. Если они непропорционально высоки, то узким местом, вероятно, является SAN.
Использовал ли ваш инструмент тестирования системную очередь или выполнял только один запрос SCSI за раз?
Подумайте о транспортировке угля из шахты в 50 метрах от вашего дома. Вы можете использовать один грузовик. С SAN шахта далеко, в другом городе. Он может производить намного больше угля (в вашем случае шахта примерно в 14 раз больше), но прежде всего вам нужно привести в действие много грузовиков (очередь).
Ваша база данных обычно приводит в действие множество грузовиков, поэтому используйте соответствующий инструмент для тестирования производительности, который также делает это.
Другое, более важное: последовательная или случайная операция. Ваша база данных наверняка нуждается в произвольном вводе-выводе (кроме времени полного резервного копирования), поэтому я могу с уверенностью предположить, что она никогда не достигнет производительности даже около 60 МБ / с. Потому что со случайным вводом-выводом майнеры работают очень медленно, поэтому грузовики и расстояние не имеют большого значения. Попробуйте протестировать такой тип нагрузки. Сравните со своим местным диском, и вы можете быть удивлены.
Еще один ответ, касающийся этой темы Какова типичная производительность SAN?.
Вот ссылка в котором обсуждается множество различных вопросов на сервере SQL. Перейдите на стр. 19 (Приложение D), чтобы узнать, как ваши ИТ-специалисты должны настроить SAN. Он включает статью Г-н Денни это мне очень помогло. Мы повторно настроили размеры блоков (размеры полос) и количество дисков на LUN в нашем SAN после прочтения и заметили примерно 100-120% улучшение в нашей среде.
Надеюсь, это поможет вам в какой-то мере ...