У меня есть два сервера A и B со следующей конфигурацией:
Я провожу следующий тест на одном разделе с RAID: iozone -a -s 10240 -r 4 -+r
Результаты из A (отрывок):
random random bkwd record stride
kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread
10240 4 108 474 4193564 6667334 6556395 701 4058822 475 3653175 2303202 2616201 6785306 6101840
Результаты из B (отрывок):
random random bkwd record stride
kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread
10240 4 3332 46961 5478410 6836065 4994841 2951 2853077 728 2299133 1722202 2008983 4549365 4712594
На обоих серверах включено кэширование со сквозной записью, но я не могу определить основную причину, по которой производительность записи на сервере A ужасно медленная (108 кБ / с) по сравнению с сервером B (3332 кБ / с), если я интерпретирую результаты правильно.
Что может быть причиной? Оба сервера имеют идентичные другие параметры файловой системы (ext4 / одинаковые параметры по умолчанию).
Может ли быть так, что диски от производителя B превосходят диски от A для рабочих нагрузок, связанных с большим количеством синхронных записей?
Спасибо.
Что касается измеренной разницы в 33 раза между вашими результатами, после нашего обсуждения в комментариях выяснилось, что MegaCli64 -LDGetProp -DskCache -Lall -aAll показало, что установка B кэш диска был включен по умолчанию, в то время как он был отключен на настройка A.
С помощью MegaCli64 -LDSetProp -DisDskCache -Immediate -Lall -aAll в результате обе системы показали схожую производительность.
Запуск RAID с включенным кешем жесткого диска фактически аналогичен запуску RAID-контроллера с энергозависимым кешем без поддержки BBU с включенным кэшированием записи (режим принудительной обратной записи). Это повышает производительность, но в то же время увеличивает вероятность потери данных и несогласованности данных в случае сбоя питания.
Если вы хотите избежать этого шанса, сохраняя при этом приличную производительность ввода-вывода, рекомендуется иметь контроллер с резервным кешем BBU и настроить свой том в режим обратной записи с отключенным кэшированием диска.
Не знаю, знали ли вы, но между программным и аппаратным RAID есть нечто большее (это интересная статья об этом).
В конце концов MegaRAID SAS 2008 г. более или менее HBA или IO-Controller с добавленными возможностями RAID, в то время как MegaRAID SAS 3108 это настоящий RAID-контроллер ™ (также называемый ROC или RAID-on-Chip), который имеет специальный процессор для обработки вычислений RAID.
SAS 2008 особенно известен ужасной производительностью записи с некоторыми OEM-прошивками (например, DELL в PERC H310, о котором я упоминал в комментарии).
Особенно синхронный режим в сочетании с выбранной длиной записи и размером файла, кажется, приводит к действительно плохим результатам с программным / поддельным RAID.
Для справки, вот что я получаю на своей рабочей станции, использующей 10k WD Velocity Raptors в программном RAID1:
random random bkwd record stride
KB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread
10240 4 182 181 1804774 2127084 2110984 167 1673159 153 1760968 954589 1203989 2022512 2062824
Если вы работаете в синхронном режиме (O_SYNC), ваш Результат А поэтому кажется разумным с точки зрения того, что может быть доставлено через soft / fake-RAID.
Я так не думаю. При активированном кэше записи контроллер может выполнять определенные операции для оптимизации отложенных операций записи.
Например, это описание операции с кешем взято из белая бумага для контроллеров HP Smart Array:
Кэш записи обычно заполняется и остается заполненным большую часть времени в средах с высокой рабочей нагрузкой. Контроллер использует эту возможность для анализа ожидающих команд записи, чтобы повысить их эффективность. Контроллер может использовать объединение записи, которое объединяет небольшие записи в соседние логические блоки в одну большую запись для более быстрого выполнения. Контроллер также может выполнять переупорядочение команд, изменяя порядок выполнения записей в кэш, чтобы уменьшить общую задержку диска.
Как вы можете прочитать, кеш используется для дальнейшего улучшения запись-производительность массива, но это не оказывает никакого влияния на производительность любых последующих операций записи или чтения.
Что касается фрагментации диска, это проблема на уровне файловой системы / ОС. RAID-контроллер, работающий на уровне блоков, вообще не может оптимизировать фрагментацию файловой системы, поэтому нет никакой разницы, работает ли он в write-trough или write-back Режим.