Основная причина сильно различающейся производительности в тесте iozone O_SYNC для двух производителей жестких дисков
У меня есть два сервера A и B со следующей конфигурацией:
- A: Жесткие диски 4 ТБ, с RAID 1 (MegaRAID SAS 2008), кэш 128 МБ, без BBU, режим сквозной записи, 7,2 тыс. Об / мин, производитель A.
- B: жесткие диски 1,5 ТБ, с RAID 1 (MegaRAID SAS 3108), кэш 64 МБ , с BBU, но с режимом сквозной записи, 10,5k RPM, производитель 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 кБ / сек), предполагая, что I a m правильно интерпретируя результаты.
В чем может быть причина? Оба сервера имеют идентичные другие параметры файловой системы (ext4 / одинаковые параметры по умолчанию).
Может ли быть так, что диски от производителя B превосходят диски от A для рабочих нагрузок, требующих большого количества синхронных операций записи?
Спасибо.
Что касается измеренной разницы в 33 раза между вашими результатами, после нашего обсуждения в комментариях выяснилось, что MegaCli64 -LDGetProp -DskCache -Lall -aAll показал, что в настройке B кэш диска был включен по умолчанию, тогда как он был отключен в настройке A .
Использование MegaCli64 -LDSetProp -DisDskCache -Immediate -Lall -aAll привел к тому, что обе системы показали схожую производительность.
Безопасно ли запускать RAID с включенным кешем диска?
Запуск RAID с включенным кешем диска фактически аналогичен запуску контроллера RAID без поддержки BBU энергозависимый кеш с включенным кэшированием записи (режим принудительной обратной записи). Это повышает производительность, но в то же время увеличивает вероятность потери данных и несогласованности данных в случае сбоя питания.
Если вы хотите избежать этого шанса, сохраняя при этом приличную производительность ввода-вывода, желательно иметь контроллер с резервным кэшем BBU и настроить том на режим обратной записи с отключенным кэшированием диска.
Разница между вашими двумя контроллерами RAID
Не знаю, знали ли вы,но между программным и аппаратным RAID есть нечто большее (, это интересная статья об этом ).
В конце концов, MegaRAID SAS 2008 более или менее является HBA или IO- Контроллер с дополнительной возможностью 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) ваш Результат A кажется разумным с точки зрения w это может быть доставлено через soft / fake-RAID.
Вызывает ли режим кэширования со сквозной записью снижение производительности массива со временем?
Я так не думаю. При активированном кэше записи контроллер может выполнять определенные операции для оптимизации отложенных операций записи.
Например, это описание операции кэширования взято из технического документа для контроллеров HP Smart Array:
Кэш записи обычно заполняется и остается заполненным большую часть время в средах с высокой нагрузкой. Контроллер использует это возможность анализировать ожидающие команды записи, чтобы улучшить их эффективность. Контроллер может использовать объединение записи, которое объединяет небольшие записи в соседние логические блоки в одну большую запись для более быстрое исполнение. Контроллер также может выполнять команду переупорядочивание, изменение порядка выполнения записей в кеше для уменьшения общей задержки диска.
Как вы можете прочитать, кэш используется для дальнейшего повышения производительности записи массива, но это, похоже, не оказывает никакого влияния на производительность любого последующие операции записи или чтения.
Что касается фрагментации диска, это проблема на уровне файловой системы / ОС. RAID-контроллер, работающий на уровне блоков, вообще не может оптимизировать фрагментацию файловой системы, поэтому нет никакой разницы, работает ли он в режиме сквозной записи или обратной записи режим.