Самый быстрый способ случайного чтения множества 300-байтовых кусков по смещению файла из файла размером 2 ТБ?

Question

В системе RAID 5 (4 x 7,2 К @ 3 ТБ) у меня есть файлы размером только 2 ТБ, доступные только для чтения (без записи).

Теперь у меня есть несколько потоков, которые хотят прочитать части этого файла.Каждый поток имеет массив кусков, в которых он нуждается.Каждый блок адресован смещением файла (позиция) и размером (в основном около 300 байтов) для чтения.

Какой самый быстрый способ чтения этих данных.Меня не волнуют циклы процессора, задержка (диска) имеет значение.Поэтому, если это возможно, я хочу воспользоваться преимуществами NCQ жестких дисков.

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

• Стоит ли объединять чтение файла в один поток?
• Должен ли я держать файл открытым?
• Должен ли каждый поток (возможно, около 30) держать каждый файл открытым одновременно, чтос новыми потоками, которые поступают (с веб-сервера)?
• Поможет ли это, если я подожду 100 мс и отсортирую свои показания по смещению файлов (сначала самое низкое)?

Что лучшеспособ прочитать данные?Есть ли у вас опыт, советы, подсказки?

Answer 1

Оптимальное количество параллельных запросов сильно зависит от факторов вне вашего приложения (например, количество дисков = 4, глубина NCQ = ?, глубина очереди драйвера =? ...), поэтому вы можете использовать систему, которая может адаптироваться или быть адаптированным. Моя рекомендация:

• Запишите все ваши запросы на чтение в очередь вместе с некоторыми метаданными, которые позволяют уведомить запрашивающий поток
• удалить из этой очереди N потоков, синхронно прочитать чанк, уведомить запрашивающий поток
• Сделать N изменяемой во время выполнения
• Поскольку ЦП не является вашей задачей, ваши рабочие потоки могут рассчитать среднее значение плавающей задержки (и / или максимум, в зависимости от ваших потребностей)
• Двигайте N вверх и вниз, пока не достигнете сладкой точки

Почему синхронизация читает? Они имеют меньшую задержку, чем ascync. Зачем тратить время ожидания в очереди? Хорошая реализация очереди без блокировки начинается с задержкой менее 10 нс, что намного меньше двух потоковых переключателей

Обновление: некоторые вопросы и ответы

Должны ли потоки чтения сохранять файлы открытыми? Да, определенно так.

Вы бы использовали FileStream с FileOptions.RandomAccess? Да

Вы пишете "синхронно читайте кусок". Означает ли это, что каждый отдельный поток чтения должен начать чтение фрагмента с диска, как только он снимет порядок чтения фрагмента? Да, именно это я и имел в виду. Глубина очереди запросов на чтение управляется счетчиком потоков.

Answer 2

Будет ReadFileScatter делать то, что вы хотите?

Answer 3

Диски "однопоточные", потому что есть только одна головка.Он не будет работать быстрее, независимо от того, сколько потоков вы используете ... на самом деле, большее количество потоков, вероятно, просто замедлит работу.Просто возьмите список и расположите его в приложении.

Конечно, вы можете использовать множество потоков, которые могли бы использовать NCQ, возможно, более эффективно, но расположение в приложении и использование одного потока должноработать лучше.

Если файл фрагментирован - используйте NCQ и пару потоков, потому что тогда вы не сможете узнать точное положение на диске, поэтому только NCQ может оптимизировать чтение.Если он непрерывный - используйте сортировку.

Вы также можете попробовать прямой ввод-вывод, чтобы обойти кэширование ОС и последовательно прочитать весь файл ... иногда это может быть быстрее, особенно если у вас нет другой нагрузки на этот массив.