Назад | Перейти на главную страницу

Лучшая производительность: 1 ТБ по сравнению с более крупными дисками в приложении с использованием только последовательного чтения / записи

У меня есть собственное многопоточное приложение; каждый поток работает на собственном логическом ядре (рабочая станция представляет собой двойной xeon с 12 физическими и 24 логическими ядрами). Таким образом, одновременно выполняется 24 потока.

Я исследовал множество вариантов хранения в течение последних 2 дней, и моя голова кружится примерно на 15 000 об / мин.

В приложении есть 2 режима, и они эксклюзивны: чтение данных или запись данных; под этим я подразумеваю, что они не будут чередовать чтение / запись. Каждый поток будет просто выполнять длинные последовательные чтения или записи. Общий объем памяти, который мне понадобится, огромен: более 50 килобайт (если вы читаете это в 2016 году, вы, вероятно, прямо сейчас посмеиваетесь над словом «огромный».)

Каждый поток будет читать или записывать файл размером около 0,8 ТБ.

Я собираюсь использовать jbod, потому что если диск выходит из строя, все, что мне нужно сделать, это заменить его, и приложение воссоздает данные примерно за 10 минут.

Я буду помещать диски во внешнюю башню или стойку, используя контроллер SATA ИЛИ SAS (еще не выяснил, какие +/- из них).

Итак, мой вопрос: правильно ли я предполагаю, что использование дисков емкостью 1 ТБ для этого конкретного приложения будет лучше с точки зрения производительности, чем использование дисков в 2, 3 или 4 раза больше? Казалось бы, если диск на 3 ТБ не имеет последовательной пропускной способности чтения / записи, которая в 3 раза больше, чем у диска 1 ТБ, лучше использовать диск меньшего размера.

Очевидно, что использование дисков емкостью 3 ТБ уменьшает количество дисков, о которых мне нужно беспокоиться, на 1/3, но это было бы соображением только в том случае, если бы я мог достичь производительности, которая находится на том же уровне, что и диски 1 ТБ.

Самое главное, что для лучшей производительности вам нужно 24 диска (или больше, потерпите меня), потому что у вас 24 потока. Если дисков меньше, чем потоков, вы делаете не иметь последовательную операцию. Учитывая два потока на одном диске, у него будет несколько поисков; Каждый поиск составляет, скажем, 10 мс, поэтому потеря возможности передачи составляет около 1 МБ. При всего 10 поисках в секунду у вас будет 90 МБ / с (2 x 45) вместо 1 x 100 МБ / с.

Думаю, вам лучше было бы с 48 дисками по 1 ТБ. Диски будут спарены, чтобы получить 24 очищенные (также известные как RAID0) группы. Вы можете предположить, что удаление, выполненное на уровне ОС, окажет незаметное влияние, поэтому фактически каждый поток получает двойную пропускную способность диска 1 ТБ.

Я не вижу возможной выгоды от накопителей на 3 ТБ с точки зрения производительности.

Тем не менее, самым большим преимуществом в производительности будет нечто совершенно иное. Просто убедитесь, что приложение передает данные эффективно - серьезно кормит очередь на жестком диске с этими командами ввода-вывода. Если он написан таким образом, что он неуклюже ожидает завершения некоторого ввода-вывода перед постановкой в ​​очередь другого ввода-вывода, то это снизит пропускную способность.

  • Лучше исправить это в самом приложении или ...
  • Чтобы частично смягчить это, вам нужно будет вложить много денег в дисковый массив с огромным дополнительным кешем.

PS. Обожаю замечание о 2016 году, привет, ребята! Вы уже получили эти ховерборды?

Учитывая, что операции выполняются последовательно и с минимальной конкуренцией, может не быть большой разницы в производительности записи между SATA и SAS.

Прочитать производительность - отдельная история. Я не думаю, что вы найдете много дисков econo SATA 15k. Диски SAS имеют тенденцию быть более высокого класса и имеют высокую скорость вращения, а контроллеры массивов SAS обычно превосходят SATA, но если вы используете econo non-RAID hba, может быть не так много разницы.

Как бы то ни было, вы должны иметь возможность достичь производительности записи не менее 100 Мбайт / с с использованием одного диска SATA емкостью 2 ТБ на стандартном контроллере без массива. Можно было бы и больше с SATA 6 Гбит / с. Для сравнения, у меня есть RAID0 с 4-мя дисками SATA по 2 ТБ (6 Гбит / с) и производительность последовательной записи 500 Мбайт / с.

Что ж, ваш ответ не должен основываться на вместимость диска, а точнее количество пластин и их плотность. Диск 7200 об / мин, последовательно считывающий 100 ГБ с диска 1,5 ТБ, состоящего из 3 пластин по 500 ГБ, будет медленнее, чем чтение тех же 100 ГБ с диска 1,5 ТБ, состоящего из двух пластин по 750 ГБ, поскольку плотность данных на последнем выше.

На самом деле вам нужно найти тесты для всех рассматриваемых дисков.

Рискну предположить, что в ситуации с ~ 18 жесткими дисками по 3 ТБ, хранящими 50 ТБ, против 50 жестких дисков по 1 ТБ, диски на 3 ТБ будут быстрее. при чтении или записи по одному файлу за раз... но опять же, все зависит от производительности отдельных дисков.

Я думаю, что есть смысл хотя бы в том, чтобы попробовать здесь RAID. Есть некоторые накладные расходы, и восстановление RAID, когда оно происходит, может в конечном итоге стать препятствием, но есть некоторые возможные преимущества.

  • Совершенно очевидно, что гораздо более простое управление
  • Пиковая производительность одного диска будет примерно 50-70 МБ / с на всем диске. Это будет быстрее на внешнем крае (например, в начале диска) и медленнее на внутреннем крае (в моих тестах обычно вдвое меньше скорости внешнего края). Если вы пишете на один диск, вы попадете в это ограничение все время. Если вы записываете на совокупность дисков (как бы это ни было управляемо), вы все равно достигнете этого предела (устойчивая производительность 4-дискового RAID0 просто в 4 раза выше производительности внутреннего края одного диска), но вы имеют более высокую совокупную пропускную способность.
  • Наборы RAID увеличат конкуренцию (если вы выполняете несколько операций записи / чтения). Они также увеличат доступную пропускную способность. Это может иметь для вас значение, а может и не иметь значения, но попробовать стоит
  • Похоже, что ваши записи - это в основном потоковая передача больших объемов данных на диск. В этом случае накладные расходы RAID5 довольно низкие, потому что, если вы записываете на диск полные фрагменты данных шириной полосы RAID, нет необходимости выполнять цикл пересчета / записи чтения / четности - ваш контроллер просто будет писать вывод новой полосы и четности одним ударом. (Четность - это дешево, мешает цикл чтения / записи)

На запись 800 ГБ данных из каждого потока уйдет около 2-3 часов. Предполагая, что ваш диск будет выдерживать около 120 МБ / с на внешнем крае и около 60 МБ / с на внутреннем крае. При 120 МБ / с ваши 800 ГБ данных займут около 111 минут, при 60 МБ / с - вдвое больше. Падение производительности записи не является линейным, но справедливо предположить, что вы потратите от 2 до 3 часов на запись этого файла размером 800 ГБ. Предложение @kubanczyk, вероятно, сократит это время вдвое, но не бойтесь переходить к более крупным агрегациям (будь то RAID0, RAID5 или RAID5 + 0)

Я плохо себя чувствую (не успел провести тесты сам), но обычно считается, что диски SAS работают лучше, даже при одинаковой скорости вращения (например, Seagate Constellation ES.2 SATA против Seagate Constellation ES.2 SAS). Некоторые из преимуществ включают полнодуплексный режим для дисков SAS и большую глубину очереди. Сравнение полнодуплексной и полудуплексной точек должно означать, что одновременные операции чтения / записи имеют меньший общий эффект. Вы по-прежнему будете сталкиваться с запросами на диск, но, например, вы не будете останавливать запись на диск в ожидании чтения.

Я строю много систем с 16-дисковыми массивами. Два набора RAID5 (аппаратные RAID-контроллеры) с программным RAID-массивом Linux поверх. Здесь мы получаем довольно хорошую производительность: где-то между 750 и 850 МБ / с во всем массиве, в зависимости от используемой модели диска. Добавление нескольких писателей добавляет конкуренции и снижает общую пропускную способность, но в зависимости от того, как часто вы записываете свои данные, а не считываете их обратно, что-то в этом направлении может помочь.

Надеюсь, я не слишком замутил здесь воду :)