RAID10 без кэша обратной записи = ужасная производительность записи?
Я только что выделил выделенный сервер на singlehop.
Я провожу некоторые тесты, чтобы знать, чего ожидать в плане производительности. На стороне ввода / вывода (с 4 дисками по 1 ТБ в RAID 10) я получаю:
write-cache disabled
200 MB/s read throughput
30 MB/s write throughput
Я думал, что это было действительно низким по сравнению с моим настольным HD, который получает 150-150 или около того. Поэтому я поболтал с ними, и они предложили включить кэш записи. Новые результаты:
write-cache enabled
280 MB/s read
260 MB/s write
Это здорово, но все это означает, что мне придется добавить BBU за дополнительную ежемесячную плату.
Это нормально для пропускной способности записи быть 1/4 от обычного диска на RAID10, если у вас нет кэша записи? Чувствуется, что намеренно плохо заставлять тебя кататься на ВВС. Я был бы счастлив с нормальным показателем без рейда 150/150.
ОБНОВЛЕНИЕ: Они смотрят на это сейчас и смотрят, есть ли что-то не так. Я дам Ахамату принятый ответ, поскольку он сломался, когда этот 8-кратный спад повлияет на нагрузку на сервер, а когда - нет. Буду обновлять снова, если я получу больше данных. +1 за другие ответы. Благодарю.
ОБНОВЛЕНИЕ 2: Похоже, что-то не так с оборудованием. Переехал на новую машину с идентичными спецификациями и получил 80 МБ / с записи без кеша обратной записи. 250 МБ / с с включенным кешем. так что 3х спад и разумная пропускная способность без него.
3 ответа
Производительность в реальных приложениях будет зависеть от характера приложения.
Асинхронные записи будут отправляться в ОЗУ, а у вас есть все, что доступно для буферизации записи. Очевидно, что запись в ОЗУ будет значительно быстрее, чем на диск. Это значение по умолчанию для большинства (всех?) Современных операционных систем. Если у вас достаточно ОЗУ для записи до тех пор, пока они не будут записаны на диск, тогда все записи будут отображаться очень быстро. Хотя есть период времени, когда потеря мощности приводит к потере данных. Буферизация записи на диск на батарейках сокращает (но не устраняет полностью) этот период.
Синхронные записи должны быть зафиксированы на диске, прежде чем запись может вернуться, и это значительно медленнее. Это режим по умолчанию для NFS и некоторых других приложений. При синхронной записи буферная запись на диск с резервным питанием от батареи значительно увеличивает кажущуюся производительность записи и устраняет риск потери данных из-за сбоев питания. Обратите внимание, что записи по-прежнему идут в энергозависимую память, они просто перемещаются в память дисковой печатной платы, а не в основную память. ZFS решила эту проблему по-другому, используя SSD ZIL, который фиксирует SSD и возвращает операцию записи, а затем перемещает ее на вращающиеся диски.
Так что вам действительно нужно посмотреть на ваше приложение. Является ли большинство ваших записей синхронными или асинхронными? Для асинхронного вы можете обойтись, просто имея объем оперативной памяти. Для синхронной работы вам понадобится кэш-память с резервным питанием от батареи (но ZFS может предложить более дешевое решение).
В любом случае вам нужно написать кеширование.
Да, вы хотите кэш с батарейным питанием. Скорость записи обычно плохая без нее. Если ваше приложение требует такой производительности, вам придется заплатить...
В сценарии RAID10 это действительно медленно даже без кеша обратной записи.
Какой инструмент вы пытаетесь использовать для измерения? Я рекомендую Фороникс для этого.
На дисках RAID10 емкостью 1 ТБ SATA последовательная запись должна составлять не менее 80–100 МБ / с, а в случайном порядке она не должна опускаться ниже 50 (конечно, это зависит и от параллелизма)