ОБНОВЛЕНИЕ: Только что попробовал этот сценарий на плате с восемью дополнительными портами SATA, и он работает. Медленнее, чем я думал, но все еще приемлемо. Согласно обсуждению с Дэвидом Шварцем, я считаю, что он может быть прав, что есть что-то патологически неправильное, или что Али Чен может быть прав, что RHEL просто не может справиться с таким количеством хост-контроллеров, работающих одновременно. Я собираюсь немного поэкспериментировать, поскольку я зашел так далеко и мне, по сути, платят за любопытство на этом этапе. :)
НАЧАТЬ ОРИГИНАЛЬНЫЙ ПОСТ
Итак, настройка немного длинная. В нашей системе есть две карты RocketU 1144D 4 port USB 3.0, одна из которых находится в разъеме PCIe 2.0, а другая — в разъеме PCIe 3.0, чтобы избежать проблем с пропускной способностью. Каждая из этих карт USB имеет четыре SSD Crucial MX300 1 ТБ в корпусах Silver Stone Raven с внешним питанием, подключенных к ней. Потребность, по словам клиента, заключается в том, чтобы иметь возможность одновременно записывать один и тот же набор файлов на четыре из восьми дисков, одновременно считывая файлы с четырех других дисков для расчета контрольных сумм MD5. Каждый диск будет максимально приближен к емкости с файлами размером примерно 1 ГБ либо во время чтения, либо после записи всех файлов.
Теперь, если мы только получаем доступ или записываем файлы на диски на одной из карт, скорости не такие уж плохие. При полном ТБ мы в среднем получаем от 3 до 4 секунд на файл (чтение/вычисление или запись). Проблема в том, что когда мы пытаемся делать и то, и другое одновременно, скорости чтения и записи довольно быстро падают, переходя от примерно 1,5 секунд на файл к более чем шестидесяти секундам на файл.
Единственными другими картами в системе являются видеокарта в слоте PCIe 3 16x и адаптер Intel X540-T2 (в настоящее время не используется) в другом слоте PCIe 3 8x.
У нас есть двухпроцессорная серверная материнская плата X10DRL-i с двумя 6-ядерными процессорами Zenon и 64 ГБ оперативной памяти под управлением RHEL 7.2 от другого Crucial MX300, подключенного к порту SATA.
Итак, вопрос в том, возможно ли сделать то, что описано выше, за приемлемый промежуток времени, определяемый как: одна тысяча файлов объемом один гигабайт на SSD, считанных с четырех SSD, подключенных к карте 1, и записанных на четыре SSD, подключенных к карте 2, причем операции ДОЛЖНЫ выполняться параллельно (из-за клиента), и все это менее чем за час?
Из того, что я узнал, я начинаю склоняться к ответу "нет", но подумал, что спрошу и посмотрю, есть ли у кого-то с большими знаниями, чем у меня, что-то более определенное. Любая помощь, совет и особенно ответ очень ценятся.
ИЗМЕНИТЬ по предложению Дэвида Шварца:
Требуемая пропускная способность на карту 5 Гбит/с на порт USB 3.0 x 4 порта = 20 Гбит/с
Доступная пропускная способность PCIe 2.0 x4 при 500 Мбит/с на линию = 16 Гбит/с
Поскольку одна карта использует линии PCIe 3, а другая — линии PCIe 2, то, насколько я понимаю, конфликта этих ресурсов быть не должно.
ПРИМЕЧАНИЕ:
Я знаю, что карта переоценена по пропускной способности, но чтение и запись не должны занимать несколько минут на файл размером в ГБ.
ПРАВКА 2:
После предложения Дэвида Шварца я отслеживал использование ядра с помощью системного монитора и htop. Система показывает 100% или около 100% использования или четыре ядра для первой дюжины файловых операций ввода-вывода. Затем система как бы зависает на несколько секунд, и в это время происходит ухудшение файлового ввода-вывода. Кроме того, использование ядра редко достигает 100% после этого, а когда это происходит, то очень ненадолго.
ПРАВКА 3: Скорее всего, это окончательная правка.
После небольшого исследования и экспериментов я думаю, что мы можем сказать, что это не будет работать для карты, которая у меня есть, и я готов поспорить, что карта StarTech, упомянутая в комментариях, тоже не будет работать. Я думаю, мы можем прийти к такому выводу, основываясь на нескольких вещах. Короче говоря, один SSD отлично работает на карте. Два работают нормально с небольшим замедлением; накладные расходы, я полагаю. Однако, 3 или более начинают делать плохие вещи. Я полагаю, это потому, что мы пытаемся протолкнуть 20 Гбит/с по 16 Гбит/с линиям PCIe, и вместо того, чтобы получить теоретический максимум 16 Гбит/с, контроллеры на обеих сторонах передачи могут споткнуться друг о друга и, как правило, заставляют все замедляться до точки, замедляющей передачу данных до ползания. Это всего лишь теория, но она была достаточно хороша, чтобы убедить клиента отказаться от требования USB и позволить нам попробовать SATA и другие методы. SATA работает намного, НАМНОГО лучше, так что я думаю, что у нас есть победитель. Спасибо Дэвиду Шварцу и Али Чену за их помощь и предложения.
ПРАВКА 4: Фактическая окончательная редакция
Итак, вчера я наткнулся на ответ на свой вопрос в нескольких частях, просматривая решения SATA. Фактическая проблема была двойной и стала очевидной только после того, как была обнаружена первая из проблем.
Итак, первой проблемой было управление памятью. Протестировав часть программного обеспечения, считывающего большие файлы для записи, мы увидели, что файлы считываются один раз, а затем записываются несколько раз. Это было не так. Итак, у нас было несколько запросов на чтение для нескольких файлов по 1 ГБ, которые происходили постоянно. Почему это работало в тестах, но не на практике, я не уверен, но у нас не было времени сделать посмертный анализ, так что это останется для истории.
Вторая проблема в том, что мы не разбираемся в оборудовании, и поэтому не знали одной очень важной детали, работая с системой Linux. Поскольку NTFS не является родной для Linux (это мы знали), по-видимому, она будет работать почти на порядок медленнее (это мы не знали). Если бы это была коробка Windows, у нас бы не было проблем.
Объедините эти два фактора вместе, и вы получите то самое странное поведение, с которым мы столкнулись. После того, как мы полностью переформатировали все диски в EXT4, мы перестали видеть непредсказуемое время чтения/записи, и все работало так, как и ожидалось. Мы могли выполнять одновременную запись и вычисления чтения/md5 в пределах допустимых параметров.