Какой самый быстрый способ чтения 10 ГБ файла с диска?

Question

Нам нужно читать и считать разные типы сообщений / запустить немного статистики для текстового файла 10 ГБ, например, FIX движок журнал. Мы используем Linux, 32-битные, 4 процессора, Intel, кодирование на Perl, но язык на самом деле не имеет значения.

Я нашел несколько интересных советов у Тима Брея Проект WideFinder . Тем не менее, мы обнаружили, что с помощью отображения памяти ограничен 32-битной архитектурой.

Мы попытались использовать несколько процессов, которые, кажется, работают быстрее, если мы обрабатываем файл параллельно, используя 4 процесса на 4 процессорах. Добавление многопоточности замедляет, может быть из-за стоимости переключения контекста. Мы пытались изменить размер пула потоков, но это все еще медленнее, чем простая многопроцессная версия.

Часть отображения памяти не очень стабильна, иногда она занимает 80 секунд, а иногда 7 секунд для файла размером 2 ГБ, может быть из ошибки страницы или что-то, связанное с использованием виртуальной памяти. Во всяком случае, Mmap не может масштабироваться выше 4 ГБ на 32-битной архитектура.

Мы попробовали Perl IPC :: Mmap и Sys :: Mmap . Смотрел в Map-Reduce, но проблема действительно в I / O связана, сама обработка достаточно быстро.

Поэтому мы решили попробовать оптимизировать базовый ввод-вывод, настроив размер буфера, тип и т. д.

Может ли кто-нибудь, кто знает о существующем проекте, где это проблема была эффективно решена на любом языке / платформе указать полезную ссылку или предложить направление?

Answer 1

В основном нужно «Разделяй и властвуй», если у вас сеть компьютеров, затем скопируйте файл 10G на максимально возможное количество клиентских ПК, чтобы каждый клиентский ПК считывал смещение файла. Чтобы получить дополнительный бонус, получите КАЖДЫЙ компьютер для реализации многопоточности в дополнение к распределенному чтению.

Answer 2

В задаче не указано, что последовательность имеет значение на самом деле или нет. Так, разделите файл на равные части, скажем, по 1 ГБ каждый, и, поскольку вы используете несколько процессоров, проблемы с несколькими потоками не будут проблемой, поэтому прочитайте каждый файл, используя отдельный поток, и используйте ОЗУ объемом> 10 ГБ, тогда все ваше содержимое будет сохранено в ОЗУ читается несколькими потоками.

Answer 3

Кажется, я вспоминаю проект, в котором мы читали большие файлы. Наша реализация использовала многопоточность - в основном n * worker_threads начинали с увеличения смещения файла (0, chunk_size, 2xchunk_size, 3x chunk_size ... n-1x chunk_size ) и читал меньшие порции информации. Я не могу точно вспомнить наши доводы по этому поводу, потому что кто-то еще все это придумал - рабочие были не единственными, но примерно так мы это сделали.

Надеюсь, это поможет