Дата  Запланированые курсы
24.11 Linux-MP. Модульная программа «Архитектура и администрирование Linux»
24.11 Linux-LE. Основы архитектуры и администрирования Linux
26.11 Поисковая оптимизация (SEO)
26.11 Средства растровой графики. Adobe Photoshop
26.11 Управление проектами (MS Project)
27.11 DEV-J30. Программирование на платформе Java. Разработка многоуровневых приложений (Группа II)
27.11 DEV-J30. Программирование на платформе Java. Разработка многоуровневых приложений (Группа I)
28.11 CORTEX-M-MP. Введение в технологии разработки систем управления на базе МК с RISC ядром ARM Cortex-M
28.11 CORTEX-M-INTRO. Введение в современную микроконтроллерную технику
03.12 Трёхмерное моделирование. 3ds Max
03.12 Компьютерное проектирование в системе AutoCAD (базовый курс)
03.12 DEV-C21. Объектно-ориентированное программирование. Углубленное изучение. Язык С++
07.12 DEV-PY200. Объектно-ориентированное программирование на языке Python
10.12 Основы создания веб-сайтов. Adobe Dreamweaver
10.12 Поисковая оптимизация (SEO) для профессионалов
10.12 Средства векторной графики. Adobe Illustrator
12.12 Инструменты бизнес-анализа Microsoft Excel: PowerPivot, PowerView
12.12 CORTEX-M-RISC. RISC-архитектура ARM Cortex-M в микроконтроллерах
17.12 MOC-20762. Разработка баз данных SQL
17.12 Работа в MS Excel. Расширенные возможности
17.12 Компьютерное проектирование в системе AutoCAD (профессиональный курс)
17.12 Adobe After Effects. Создание анимации и эффектов
09.01 DEV-C22. Стандарт С++11, С++14, С++17 для прикладного программирования
14.01 DEV-OCPJP. Подготовка к сдаче сертификационных экзаменов серии Oracle Certified Professional Java Programmer
14.01 DEV-OCPJP. Подготовка к сдаче сертификационных экзаменов серии Oracle Certified Professional Java Programmer
16.01 CORTEX-M-STM32F. Семейство МК компании ST Microelectronics STM32Fxxx с вычислительным ядром ARM Cortex M3
19.01 Linux-LF. Расширенное администрирование ОС Linux
04.02 DEV-QT10. Прикладное программирование на С++ с использованием Qt. Базовый уровень
11.02 DEV-J60. Технологии разработки корпоративных приложений на платформе Java Enterprise Edition (Java EE)
11.02 DEV-J60. Технологии разработки корпоративных приложений на платформе Java Enterprise Edition (Java EE)
13.02 CORTEX-M-RTOS. Разработка управляющих программ для МК систем управления с использованием многозадачных ОС реального времени
11.03 Введение в тестирование программного обеспечения
11.03 Введение в тестирование программного обеспечения
11.03 Введение в тестирование программного обеспечения
20.03 NET-DLINKSW-LAB. Технологии коммутации современных сетей Ethernet. Лабораторный практикум
Открыт набор на осенний семестр в Академию информатики для школьников Открыт набор на осенний семестр на программы второго высшего образования
Добро пожаловать, Гость! Чтобы использовать все возможности Вход или Регистрация.

Уведомление

Icon
Error

Что значит 6 Гбит/с для RAID контроллера
Shek
#1 Оставлено : 16 февраля 2011 г. 15:44:41(UTC)
Ранг: Активный Участник

Группы: Зарегистрированные пользователи
Зарегистрирован: 09.02.2009(UTC)
Сообщений: 146
Баллов: 438
Откуда: Russia Питер

Здравствуйте!

Подскажите, пожалуйста, что за характеристика RAID контроллера "пропускная способность 6 Гбит/с" которую так любят писать производители? То есть по логике-то понятно что такое пропускная способность, но вот пример:

Есть RAID контроллер PERC H700 6Gb/s SAS PCI-Express 2.0 x8 с возможностью подключения 2х4 дисков. Меня смущает, что нигде не написано что такое 6Гбит/с - это общая пропускная способность контроллера или это на каждый физический диск? Если на каждый диск, то непонятно, почему в рабочей операционной системе скорость копирования с одного RAID1 из 2-х жестких дисков SAS 6G на другой такой же RAID1 составляет 50-60 Мбайт/с, что соответствует скорости примерно 0,5 Гбит/с, так где же заявленные 6!? Даже если это 6G на весь контроллер, все равно 4 физических диска, то есть по 1,5G на каждый, почему даже близко я не вижу такой скорости?

Плюс еще вопрос, если 6 на каждый диск причем как в одну, так и в обратную сторону и всего дисков может быть в данном контроллере 8, то получается в целом на контроллер на одно направление 48 Гбит/с, но сама плата контроллера вставляется в слот PCI-Express 2.0 x8, пропускная способность которого в одну сторону, насколько мне известно составляет 32 Гбит/с, то есть в максимальной загрузке RAID контроллера мы получим только 2/3 от максимума. Но это опять же просто расчеты, на практике я не могу получить даже 1 Гбит/с, при том, что сервер Dell R410 с 4 дисками SAS 6G и RAID контроллером H700 с 1-Гбайтным кэшем.

Помогите разобраться, что же такого важного я не знаю или не понимаю?
Реклама
Alexander.Smirnov
#2 Оставлено : 17 февраля 2011 г. 1:47:32(UTC)
Alexander.Smirnov

Ранг: Активный Участник

Группы: Администраторы, Зарегистрированные пользователи
Зарегистрирован: 07.06.2007(UTC)
Сообщений: 48
Баллов: 144
Мужчина
Откуда: Russia, Saint-Petersburg

Поблагодарили: 3 раз в 3 постах
Скорее всего эта характеристика относится к интерфейсам SAS, которые используются для подключения дисков, т.е. не более, чем указание на стандарт пропускной способности шины SAS (есть ведь SAS и на 3Гбит/c).
Имеется ввиду блочный доступ к данным (а не на уровне используемой файловой системы).
Если оценивать "пропускную способность" каждого из подключенных дисков, то разработчики шины/протокола заявляют о достижении указанной скорости при блочной передаче данных на каждом из подключенных к шине устройств (т.е. на каждом диске) - в отличие, например от SCSI, где "пропускная способность" делится между всеми подключенными устройствами.

P.S. По характеру вопроса топик больше вхож в раздел "организация ЭВМ и систем", <на правах администратора> - перемещён в соответствующий раздел.
Shek
#3 Оставлено : 17 февраля 2011 г. 4:02:52(UTC)
Ранг: Активный Участник

Группы: Зарегистрированные пользователи
Зарегистрирован: 09.02.2009(UTC)
Сообщений: 146
Баллов: 438
Откуда: Russia Питер

Спасибо за ответ.
Занчит, получается, что загрузить шину SAS в NTFS даже используя диск SAS 6Гбит/с не получится. А как на счет твердотельных дисков, с ними получится добиться максимальной пропускной способности?
И вопрос к специалисту - как влияет на скорость записи RAID-1 и RAID-10?
Eugene.Norka
#4 Оставлено : 17 февраля 2011 г. 14:11:32(UTC)
Ранг: Активный Участник

Группы: Зарегистрированные пользователи
Зарегистрирован: 28.01.2005(UTC)
Сообщений: 52
Баллов: 156
Откуда: Russia СПб

Сказал(а) «Спасибо»: 1 раз
Поблагодарили: 3 раз в 3 постах
В общем, согласен с Александром. Контроллер SAS обеспечивает заявленную пропускную способность (6.0 Гбит/с) на каждом соединении инициатор - целевое устройство (диск). В ваших тестах все очень правильно и получилось: скорость трансфера порядка 60 Мбайт/с на зеркале из двух дисков. К тому же RAID 1 сам по себе скорости не прибавляет. Что касается скорости записи RAID-1 и RAID-10 – скорость различается в разы, так как 10 RAID использует чередование. Насчет твердотельных дисков, если кратко, их главная “фишка” – скорость случайного доступа (характеристика Iops), существенного прибавления скорости потоковой передачи (transfer rate) – не получите.
Alexander.Smirnov
#5 Оставлено : 17 февраля 2011 г. 14:22:18(UTC)
Alexander.Smirnov

Ранг: Активный Участник

Группы: Администраторы, Зарегистрированные пользователи
Зарегистрирован: 07.06.2007(UTC)
Сообщений: 48
Баллов: 144
Мужчина
Откуда: Russia, Saint-Petersburg

Поблагодарили: 3 раз в 3 постах
Скорее всего нет, не получится [:(]
Доступ на уровне файлов - это "виртуальный блочный доступ", только от приложения в этом случае скрываются процессы адресации данных на носителях, т.к. доступ осуществляется по имени и пути к файлу, однако операции по вычислению местоположения данных производятся и это "накладывает свой отпечаток" на производительность, кроме этого все журналируемые файловые системы (в т.ч. NTFS) ведут журнал операций, т.е. помимо данных на носителях ещё производятся операции над метаданными. Конечно эти процессы оптимизируются и решающими в вычислении скорости доступа к данным уже не являются, но всё-таки.

Когда производитель рекламирует товар (жёсткий диск, RAID-контроллер), то он, как правило, указывает, так называемую "внешнюю скорость передачи", т.е. от шины -> к буферу диска. А реально оценивают ещё и понятие "внутренней скорости передачи" - т.е. при адресации логических блоков при выполнении операций ввода/вывода, инициируемых приложением. Если использовать твердотельные микросхемы памяти, то рискну предположить, что "внутренняя скорость передачи" улучшится, улучшая и общую "пропускную способность", но до пропускной способности шины SAS она всё равно, боюсь, не дотянет (я таких SSD не встречал).
Спасибо за столь лестную характеристику [;)] - я конечно же не являюсь крупным специалистом, но, чёрт возьми, приятно [:)] - если сравнивать RAID 1 и RAID 10 в плане их влияния на производительность: при небольших размерах передаваемых данных, скорее всего разницы не будет вообще никакой (всё равно для ускорения работы используется кэш). Правда RAID 10 способен обеспечить лучшую скорость чтения - т.к. сегментированное зеркало даёт возможность обращения к сегменту данных (используется преимущество RAID 0 по сравнению с единичным диском) - но он в минимальной конфигурации естественно обходится дороже.
Shek
#6 Оставлено : 17 февраля 2011 г. 20:58:40(UTC)
Ранг: Активный Участник

Группы: Зарегистрированные пользователи
Зарегистрирован: 09.02.2009(UTC)
Сообщений: 146
Баллов: 438
Откуда: Russia Питер

Спасибо за разъяснения. Многое стало понятно.
Вот что, кстати, вычитал из "Troubleshooting Performance Problems in SQL Server 2008" - будет интересно всем:
• Raid 1 -- I/Os per disk = [reads + (2 * writes)] / 2
• Raid 5 -- I/Os per disk = [reads + (4 * writes)] / number of disks
• Raid 10 -- I/Os per disk = [reads + (2 * writes)] / number of disks

Так что RAID 10 в любом случае как минимум 2 раза больше IOPS'ов может обработать, при условии что контроллер конечно может.

Так вот вернемся к твердотельным дискам - я так понимаю, что они существенно сокращают время каждого отдельного обращения к диску на чтение и точно также на запись, сответственно, отодвигается уровень при котором данное количество I/Os создаст затор, то есть твердотельные диски, как нельзя лучше подходят для системных разделов, в то же время использование их для хранения какого-нибудь одного отдельного файла какой-нибудь одной базы данных нецелесообразно, учитывая к тому же объемы твердотельных дисков.
Eugene.Norka
#7 Оставлено : 18 февраля 2011 г. 16:48:24(UTC)
Ранг: Активный Участник

Группы: Зарегистрированные пользователи
Зарегистрирован: 28.01.2005(UTC)
Сообщений: 52
Баллов: 156
Откуда: Russia СПб

Сказал(а) «Спасибо»: 1 раз
Поблагодарили: 3 раз в 3 постах
IMHO, конечно. Но касательно SSD у меня сформировалось ровно противоположное мнение - как раз для "горячих", нагруженных приложений с большой транзакционной активностью (суть СУБД) их и стоит использовать. Вообще тема очень многогранная, влияют уйма факторов. По большому счету, кмк, "классический" рейд на SAS, даже SATA, дисках во многих случаях достаточен и сбалансирован по соотношению цена-объем-производительность-надежность. Посмотрите, например, обсуждение на форуме DB'шников: www.sql.ru/forum/...lthread.aspx?tid=714436 (особенно ссылки внутри треда) - люди всерьез рассматривают 2 диска SSD (притом второй для отказоустойчивости, а не для скорости) как альтернативу рейд группе из 4-х SAS.
Shek
#8 Оставлено : 18 февраля 2011 г. 18:21:57(UTC)
Ранг: Активный Участник

Группы: Зарегистрированные пользователи
Зарегистрирован: 09.02.2009(UTC)
Сообщений: 146
Баллов: 438
Откуда: Russia Питер

Спасибо!
Я как раз сейчас и рассматриваю вопрос об улучшении подсистемы ввода/вывода, так как с ней у нас сейчас полный кю! Купили одноюнитовые сервера с 4 дисками, а потребовалось больше объема, был маленький qnap (сетевое хранилище), от него отрезали iscsi LUN и подключили к тестовому SQL, перебросили пару файлов одной из БД - разнесение файлов БД на разные диски дало неплохую прибавку к производительности, поэтому приняли решение и купили дорогое сетевое хранилище с iSCSI, но после его подключения я стал наблюдать серьезные проблемы: если копировать файлы с помощью windows explorer - скорость под 80-100 Мбайт/с, но как только дело доходит до sqlserv.exe он читает и пишет в файлы, которые лежат на iscsi диске со скорость максимум 10-20 Мбайт/с, и что характерно, если делать операцию РАСШИРЕНИЯ файла путем задания его размера больше существующего в свойствах файлов БД, то скорость возрастает до максимума 80-100 Мбайт/с... Вот такая вот проблема...

Так что сейчас у меня задача написать проект с обоснованием и расчетами. Кстати, о расчетах - подскажите как расчитать требуемое количество IOPSов для конкретного сервера SQL, чтобы под это подобрать нужную конфигурацию подсистемы ввода/вывода?
Eugene.Norka
#9 Оставлено : 18 февраля 2011 г. 20:05:33(UTC)
Ранг: Активный Участник

Группы: Зарегистрированные пользователи
Зарегистрирован: 28.01.2005(UTC)
Сообщений: 52
Баллов: 156
Откуда: Russia СПб

Сказал(а) «Спасибо»: 1 раз
Поблагодарили: 3 раз в 3 постах
Ну, думается, можно пойти просто эмпирическим путем: замерить нагрузку (дисковая очередь, IOPS и т.д.), которую генерирует база каким-либо средством на самом сервере БД (тем же перфмон под Windows), затем, использую точные данные и, исходя из ТТХ той, или иной СХД - выбрать само хранилище. Но, опять же, надо помнить, что вводных много и эта оценка сайзинга будет весьма приблизительна. Но как отправную точку для "проекта с обоснованием", думаю, использовать можно.
Shek
#10 Оставлено : 18 февраля 2011 г. 22:29:22(UTC)
Ранг: Активный Участник

Группы: Зарегистрированные пользователи
Зарегистрирован: 09.02.2009(UTC)
Сообщений: 146
Баллов: 438
Откуда: Russia Питер

Да, уже собираю перфмоном общую картину. А по поводу сетевого хранилища, честно говоря, думаю, что для sql сервера оно все-таки не подходит, нужно подключать внешний RAID напрямую. Про твердотельные диски почитал и что-то отпало у меня желание их ставить (оч хорошая статья www.fcenter.ru/on...cles/hardware/hdd/23761)... =)

Вот еще вопрос с примером:
Есть MS SQL 2008 R2, на нем три пользовательские БД.
Одна маленькая (несколько Гб) в которую непрерывно в реалтайме откуда-нибудь с небольшой скоростью поступает информация и точно так же с небольшой скоростью но постоянно она читается (как показывает перфмон реч идет о 30-60 IOPS'ах, в общем главное минимальный jitter как в сетях).
Другая огромная (несколько сотен Гб, в обозримом будущем за Тб перевалит). Основное требование - максимальная скорость чтения при обращении к базе нескольких десятков клиентов, а запись в нее производится по ночам когда никто ничего из базы не читает.
Третья черновая база средних размеров (от десятков до пары сотен Гб), ничем не примечательная, никаких к ней требований, ни по скорости обработки запросов ни по пропускной способности, просто такая черновая тестовая база.

Так вот все это мы планируем крутить на одном сервере sql и, думаю, что надо делать так:
сервер с 16 дисками SAS 15k 6Gbps 146G, 4 RAID контроллера в 4 PCI-E v2.0 x8, по 4 диска на контроллер в RAID 10, в итоге в системе 4 отдельных диска по 300 Гб, на одном система и сам установленный sql сервер с системными БД, кроме tempdb, на другой tempdb, на следующий маленькую базу, на последний черновую. А еще через один слот PCI-E 2.0 x16 подключить внешний RAID, в котором все или не все :) диски собрать в RAID 10 и на нем разместить большую базу, а за счет RAID 10 с большим количеством дисков получить большую скорость чтения (ну заодно и записи). Еще подумываю о том, чтобы 4 диска на одном из контроллеров собрать не в 10 RAID, в два 1-х, и полученные два диска пустить один под маленькую базу, другой под черновую, а на освободившийся 10-й закинуть файл подкачки, хотя на счет файла подкачки у меня нет однозначного ответа, кто говорит, что он вообще не нужен, если много ОЗУ, кто-то говорит, что без него никак, кто-то пишет, что sql cервер его не использует, а по факту видно что использует - любой запрос на выборку нескольких десятков миллионов строк и в этот файл начинается интенсивная запись, в общем не знаю нужно ли его выносить на отдельный диск.

Как думаете правильно я мыслю или на что еще обратить внимание? Может оно все упрется в то, что будет много PCI-E устройств и они будут мешать друг другу? (надо спецификацию почитать, кстати, про PCI-E).

Объясните еще такое загадочное для меня понятие как длина очереди команд (и где оно вообще меняется и чем регулируется)?
Eugene.Norka
#11 Оставлено : 19 февраля 2011 г. 3:45:01(UTC)
Ранг: Активный Участник

Группы: Зарегистрированные пользователи
Зарегистрирован: 28.01.2005(UTC)
Сообщений: 52
Баллов: 156
Откуда: Russia СПб

Сказал(а) «Спасибо»: 1 раз
Поблагодарили: 3 раз в 3 постах
Как мне кажется, вы мыслите в абсолютно правильном направлении. Учитывая указанные задачи, я бы тоже рассматривал дисковую на платформе сервера, или небольшой внешний массив начального класса, полноценный SAN вряд ли требуется (да и NAS не подходит в любом случае). Но, учитывая, что вы уже приобрели “дорогое” iSCSI хранилище (какой производитель и модель, если не секрет?) можно было бы все-таки использовать и имеющееся мощности (подключен по гигабиту?). В плане “разбиения” на конкретные рейд и дисковые группы – здесь догм нет, ваш вариант видится вполне рабочим (под файл подкачки я бы все-таки выделил хоть какой-нибудь том). Что-то конкретное в этой ситуации советовать я не решусь. Мне приходится более “академическими” вещами заниматься, экспертный совет смогут дать на специализированных ресурсах, например форуме компании Тринити , IXBT, или том же Fcenter. Может, чего подскажут и другие участники нашего форума. По поводу дисковой очереди – одна их ключевых характеристик дисковой подсистемы, которую все и всегда, как правило, проверяют вне зависимости от типа приложений и нагрузки. С ней все просто – чем выше – тем хуже (не хватает производительности контроллера/дисков/кэша на обработку “стоящих в очереди” команд).
Shek
#12 Оставлено : 20 февраля 2011 г. 3:17:32(UTC)
Ранг: Активный Участник

Группы: Зарегистрированные пользователи
Зарегистрирован: 09.02.2009(UTC)
Сообщений: 146
Баллов: 438
Откуда: Russia Питер

Сетевое хранилище гигабитное Thecus n8800 SAS, не DELL EMC, конечно, но 90к все-таки не дешево (очень разочаровал тот факт, что при емкости в 8 дисков можно создать всего 3 RAID'а, вклюачая JBOD, если использовать диски по отдельности и совсем никакой support, не покупайте thecus).
На счет очереди, мы, видимо, не поняли друг друга. Я имел в виду не ту очередь к диску, которую показывает перфмон, а глубину очереди команд о которой пишут в тестах www.fcenter.ru/on...les/hardware/hdd/23761, вот цитата:
"С помощью теста "Database" мы выясняем способность накопителей работать с потоками запросов на чтение и запись 8-кБ блоков данных со случайной адресацией. В ходе тестирования происходит последовательное изменение процентного соотношения запросов на запись от нуля до ста процентов (с шагом 10 %) от общего количества запросов и увеличение глубины очереди команд от 1 до 256.
Рассмотрим диаграммы с результатами для глубин очереди команд, равных 1, 16 и 256.
...
"
На тестах видно, что чем больше значение этой глубины, тем больше IOPS'ов.
Eugene.Norka
#13 Оставлено : 21 февраля 2011 г. 19:13:07(UTC)
Ранг: Активный Участник

Группы: Зарегистрированные пользователи
Зарегистрирован: 28.01.2005(UTC)
Сообщений: 52
Баллов: 156
Откуда: Russia СПб

Сказал(а) «Спасибо»: 1 раз
Поблагодарили: 3 раз в 3 постах
То есть речь шла о функциях, встроенных в контроллер диска, типа Native Command Queuing (NCQ) и Tagged Command Queuing (TCQ)? В основном, считается, что преимуществ больших они не дают: "NCQ is designed to improve throughput of multiple concurrent I/Os on traditional spinning hard drives. It re-orders the I/Os to minimize the number and distance of head movements. Since SSDs have neither spinning platters nor disk heads, they don't really benefit from NCQ". Ну уж в любом случае по этому критерию SSD не уступят классическим ЖД.
PS по поводу Thecus - а смотрели в сторону настройки и оптимизации прикладного уровня (sql)?
Shek
#14 Оставлено : 3 марта 2011 г. 21:52:29(UTC)
Ранг: Активный Участник

Группы: Зарегистрированные пользователи
Зарегистрирован: 09.02.2009(UTC)
Сообщений: 146
Баллов: 438
Откуда: Russia Питер

Немного в другое русло пошел у нас разговор, но, думаю, в любом случае он будет полезен.
Еще один крайне занимательный момент - размеры блоков данных, и как от этого зависит производительность - www.sqlservercent...ze-and-io-patterns.aspx
Плюс к этому тоже очень интересная информация про то как правильно разбивать диски - msdn.microsoft.co...814%28v=sql.100%29.aspx

Результаты:
1 В своем первом сообщении я писал про скорость дисков в 50-60 Мбайт/сек, а вот после этих ссылок, особенно второй, удалось получить скорость копирования с одного RAID 1 (на котором работает система) на другой RAID 1 (пустой) в 250-350 Мбайт/сек с пиком вначале 600 (но его, думаю, брать в расчет не стоит)
2 В настройках iSCSI на сетевом хранилище можно указывать размер блоков данных (либо 512 байт, либо 4К), так вот по умолчанию он стоял 512 байт, что в общем-то даже не соотносится с дефолтным размером кластера в NTFS (4К), но я раньше на это и не смотрел, просто не владел информацией. Был проведен тест - на сетевом хранилище поставлен блок 4К, на сервере этот диск форматировался в NTFS с разными значениями блоков, как и стоило ожидать максимальная скорость, минимальные задержки, IOPS'ы и очереди наблюдаются при размере кластера NTFS 4К.
Вот так вот ;)
RSS Лента  Atom Лента
Пользователи, просматривающие эту тему
Guest (2)
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.