У меня проблема с производительностью с хранилищем данных SQL Server на блейд-сервере, подключенном к IBM Shark. Производительность дискового ввода-вывода кажется патологически низкой из-за чрезмерного времени ожидания блокировки страницы. Другие люди, работающие над проектами MIS на основе SQL Server, сообщают о подобных симптомах, но очевидного решения нет. Вот некоторые тесты, которые я пробовал:
Создание некоторых или всех томов на шевлесах, настроенных как RAID-10. Это не имело заметного эффекта.
Отключение принудительной сквозной записи на SQL Server (это может быть плацебо - см. Ниже).
Ни один из тестов существенно не повлиял на скорость, и система будет тестировать примерно вдвое быстрее на машине с в целом аналогичным оборудованием и спецификациями O / S (Windows 2003 server EE) с массивом SCSI с прямым подключением. В SAN у меня есть три тома по 8 дисков в каждом (журналы RAID-10, RAID-10 tempdb, данные RAID-10). На машине с дисками прямого подключения у меня было 6 внутренних и 14 внешних 10k SCSI-дисков.
Обратите внимание, что у Shark было 32 ГБ кэш-памяти, чего должно было быть достаточно, чтобы соответствовать рабочему набору приложения при тестировании.
Одним из направлений, которое я исследовал, была программа сертификации SQL Server для хранилища SAN, в которой SAN учитывала операции ввода-вывода с помощью принудительного набора битов сквозной записи. Я смог найти документацию по SAN EMC, HP и Hitachi, в которой заявлено о соответствии этому стандарту, но не смог найти такой литературы для Shark.
Кто-нибудь сталкивался с подобными проблемами производительности на Shark - если да, то есть ли у вас какие-либо идеи по этому поводу?
Если вы ознакомитесь с моими инструкциями по измерению производительности SAN здесь:
http://sqlserverpedia.com/wiki/SAN_Performance_Tuning_with_SQLIO
Опубликуйте результаты текстового файла где-нибудь в Интернете и включите ссылку на него в свой вопрос. Это должно помочь нам определить ограничение скорости.
Кроме того, как вы подключаетесь между сервером и SAN? Сколько адаптеров главной шины вы используете и какое программное обеспечение для работы с несколькими путями вы используете? Если вы используете только 2 HBA или если вы не используете программное обеспечение с несколькими путями, вы довольно рано достигнете предела пропускной способности. С чем-то вроде Shark вы захотите использовать как минимум 4 HBA и хорошее активное / активное программное обеспечение для работы с несколькими путями, чтобы получить хорошую пропускную способность.
Какой тип ввода-вывода отчет по акулам переносится на диск? Акула показывает, что идет очередь? Какое время отклика показывает SAN?
Сколько кеша у SAN? Используют ли SAN и другие системы? Как выложен кеш на SAN?
Если вы смотрите на Windows только для того, чтобы вернуть цифры, вы не понимаете всей истории, поскольку SAN маскирует некоторые из этих настроек.
Я видел это также с Sybase и Oracle. Оборудование Shark работает хуже, чем локальный диск.