LINUX.ORG.RU

[parallel][I/O] как делают настоящие джедаи?


0

0

Братья,

у меня вопрос следующего плана. Есть очень много входных данных (около 10^4 файлов различной длины). Данные надо почитать, проверить определённым способом и в зависимости от результатов проверки либо записать в новый файл, либо проигнорировать. Есть также много компов. Каждый комп многоядерный (4 ядра). Данные лежат в сети (пусть будет гигбитный езернет) и примонтированны к каждому компу как NFS партишн. Хочется, чтоб всё было как можно параллельно.

Проблема в чтении файлов. Сейчас я делаю след образом. Пока ограничиваюсь одим компом, но в перспективе использовать надо больше. Каждый тред/поток читает свой собственный входной файл. Каждый поток решает что с ними делать и в случае успеха записывает в свой собственный выходной файл. В итоге имеется стрёмная производительность. Согласно top каждый тред/поток поедает только около 10 процентов процессорного времени, что свидетельствует о том, что имеют место простои.

Понятно, что всё дело в вводе/выводе. Потом я подумал, что пусть только один тред/поток читает данные и занимается их раздачей другим участникам.

Но прежде, чем ломать дрова, решил проконсультироваться у народа. Как делают нормальные люди с прямыми руками в таких случаях? Стоит ли искать истину в середине? Типа k потоков читают информацию и раздают её n-k потокам для обработки.

Кроме вышеупомянутых компов есть один очень мощный суперкомп с GPFS, который почти справляется в первым подходом. Согласно топ каждый поток поедает 75% CPU времени. Тем не менее хочется большего.

Теперь к техническим деталям. линукс, gcc, пока OpenMP, но в перспективе MPI или гибрид. Для I/O использую стандартную сишную библиотеку.

Извините, если объяснил невнятно. Если что, спрашивайте.


какой суммарный объем данных ?
как часто они пополняются ?

если операцию обработки одного файла разделить на:
1. чтение с диска
2. обработка процессором
3. запись на диск
то какое время в процентах затрачивается на каждый пункт?

как вариант можно сделать так:
1. на комп, где находятся файлы поставить БД - она будет выдавать данные по сети клиентам, заодно и обеспечит чтобы никто не хватал один и тотже файл
2. на другые компы (или на тотоже) поставить клиентов для обработки данных (на многоядерные компы - 2,4 клиента запустить)

x905 ★★★★★ ()
Ответ на: комментарий от x905

спасибо за ответ.

Объём данных вариируется в зависимости от конкретного случая. В зависимости от задачи объём данных может быть скажем от 100Гб до 10Тб.

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

Теперь по поводу производительности вышеуказанных пунктов. Если данные «подготовить», т.е. пробежаться один раз по ним и раскидать по кучкам, то ввод/ввывод будет сущственно доминировать. Скажем второй пункт займёт не более 10%. По сути подготовка данных имеет тот же принцип: чтение->обработка->запись. Опять же здесь чтение/запись доминируют.

Если, не «подготавливать», то будет иметь место параллельный доступ к расшаренной хэш-таблице. Пока я не знаю, сколько времени это будет стоить. однако, в этом случае, возможно будут проблемы с нехваткой памяти для хэш-таблицы. С поготовленными данными этого можно избежать.

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

rha ()

development такой development =)
ты не сказал самого главного - какое у тебя хранилище

val-amart ★★★★★ ()
Ответ на: комментарий от rha

не совсем понял что значит «пройтись по данным и раскидать их по кучкам» ?
и что «за расшаренная хэш таблица» ?

я полагал так (для мелких данных, но к долгой обработки на процессоре) - пришли данные (очередная порция) на сервер, он оповестил клиентов об этом, свободный клиент ответил готовностью и получил данные на обработку, обработал и отправил обратно на сервер

если же основные тормоза изза диска - то и гонять данные по сети незачем - надо делать в процессах сервера (2,4,8 шт), при этом подумать о совместном параллельном доступе к диску на чтение и запись (о дефрагментации) и как решение поставить физический второй диск только для готовых данных

x905 ★★★★★ ()
Ответ на: комментарий от rha

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

val-amart ★★★★★ ()

Нужно выяснить экспериментально, сколько данных успевает обрабатывать N ядер и сколько данных успевают читать M ядер за одно и то же время. Если сеть не шибко крутая, то вполне может быть, что двумя потоками прочитаешь не больше, чем одним. Так или иначе, зная результаты, можно балансировать нагрузку. Либо статически, если все компы одинаковые, либо динамически.

const86 ★★★★★ ()

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

Пусть скорость измеряется в МБ/с. Тогда быстрее будет считывать файлы с винчестера со скоростью V1 и обрабатывать их со скоростью V2, чем передать их со скоростью V3, если (V1+V2)>(V1+V3).

Если решение, что делать с файлом принимается не за время пропорциональное длине файла (а квадрат например) - тогда другой разговор. Но все равно надо посчитать, может ли быть выигрыш от параллельной обработки, какой для выигрыша должен быть размер файлов и т.д.

tim239 ()

джедаи гугла вообще предпочитают использовать MapReduce для подобных задач. хотя в данном случае это, наверно не подойдёт (код уже готов, как я понимаю?)

Zloddey ()
Ответ на: комментарий от val-amart

Всем спасибо за ответы. Есть над чем подумать.

Данные находятся в текстовых файлах. Файлы хранятся либо на NFS сервере, либо на GPFS storage system с параллельным доступом.

rha ()
Ответ на: комментарий от rha

> Файлы хранятся либо на NFS сервере, либо на GPFS storage system с параллельным доступом.

это-то ты указал и в первом посте, но это указывает только на способ доступа к данным, и никак - на параметры доступа. nfs шара - это что? какое железо, какие блины, сеть? вообщем, нужно знать, что тебе может дать сторедж, чтобы считать что из этого ты сможешь переживать, и сколько дополнительных потоков можно запустить, чтобы забить под завязку ио.

val-amart ★★★★★ ()
Ответ на: комментарий от val-amart

теперь ясно, что ты имел ввиду. пока это для меня blackbox. сервера не под боком, но разузнать конечно всё можно. В общем, направление понятно, буду работать.

rha ()
Ответ на: комментарий от Karapuz

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

rha ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.