потенциальная неверная конфигурация SAN?

MSA1500s не то, что быстро по стандартам SAN, но неправильно сконфигурировал SAN, часто показывают низкие результаты на загрузках, таких как хранилища данных. Это, довольно вероятно, будет неправильно сконфигурированный SAN (возможно, размер дорожки на массиве является слишком небольшим). Также возможно, что SAN является по сути медленным - не, все SAN создаются равные.

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

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

Для понимания то, является ли что-то сидячим, смотрят на статистику для Страницы Фиксатор IO, ожидает. Если они непропорционально высоки затем, SAN является, вероятно, узким местом.

У меня есть MSA1500CS, и он последовательно показывает низкие результаты для меня приблизительно на уровнях, которые Вы испытываете. Диски в моем являются дисками SATA. Когда у меня были они в конфигурациях набега четности (RAID5 или 6), пропускная способность была вокруг 60MB/s. Контроллеры там находятся действительно под приводимым в действие. Я с тех пор перешел к RAID10, и пропускная способность увеличилась вполне немного, в основном потому что я не использую почти столько же контроллера ресурсы ЦП для четности-calcs.

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

Тем не менее у Вас есть диск SCSI там не SATA. Это должно помочь производительности хорошей суммой, хотя снова четность RAID не может улучшиться очень. То, что улучшило бы производительность, использует Активное/Активное встроенное микропрограммное обеспечение на ней и использует MPIO вокруг - robbin для распределения нагрузки ввода-вывода между обоими контроллерами. В последний раз я проверил, это могло только быть сделано в гомогенных средах ОС хоста (т.е. весь Windows или весь Linux).

Это - устройство, разработанное таким образом, что чувствительные к задержке рабочие нагрузки (рабочие нагрузки "онлайн" в языке HP) предназначаются, чтобы быть выполненными в зеркальном наборе и рабочих нагрузках архивирования ("nearline" рабочие нагрузки) для НАБЕГОВ четности. Попытка использовать четность, RAID в роли онлайн является выполнимым, пока приложение принимает потенциально очень серьезной задержки. Мои не были, и это вызвало основные проблемы.

Строка MSA2000 по сообщениям намного лучше об этом.

Общие преступники:

• Разделы диска Windows не выровненные SAN. Это происходит из-за версий Windows Server до 2008 стартовые разделы в 64-м секторе.

• Размер единицы выделения NTFS должен быть 64k (лучшая практика).

• Субоптимальный размер дорожки SAN

Можно проверить выравнивание дисков с командой:

раздел wmic получает blocksize, startingoffset, имя, индекс

Если начальное смещение 32256, раздел неправильно выравнивается.

Больше информации:

Лучшие практики выравнивания раздела диска для SQL Server

http://msdn.microsoft.com/en-us/library/dd758814.aspx

Ваш инструмент сравнительного теста использовал очередь системы или работал, только один SCSI запрашивают время?

Думайте о переносе угля от шахты, которая является в 50 метрах от Вашего дома. Можно использовать один грузовик. С SAN шахта далеко в другом городе. Это может производить намного больше угля (в Вашем случае, шахта является приблизительно в 14 раз более большой), но в первую очередь необходимо привести много в действие грузовиков (очередь).

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

Другая вещь, более важная: последовательный по сравнению со случайной операцией. Вашей базе данных наверняка нужен случайный ввод-вывод (кроме времени полного резервного копирования), таким образом, я могу безопасно предположить, что это никогда не будет прибывать даже около производительности на 60 МБ/с. Поскольку со случайным вводом-выводом шахтеры работают действительно действительно медленно, таким образом, грузовики и расстояние не имеют значения так очень. Попытайтесь сравнить такого типа рабочей нагрузки. Сравните со своим локальным диском, и Вы могли бы быть удивлены.

Другой ответ, который касается этого предмета, Что такое типичная производительность SAN?.

Вот ссылка, которая обсуждает много других вопросов о SQL-сервере. Перейдите к странице 19 (Приложение D) для получения инструкций относительно того, как Ваши парни IT должны настроить SAN. Это включает статью г-на Denny, который был очень полезен мне. Мы реконфигурировали размеры блока (размеры дорожки) и количество дисков на LUN на нашем SAN после чтения и заметили приблизительно 100-120%-е улучшение нашей среды.
Надежда это помогает Вам в некотором роде...