PARALLEL.RU

Добрый день!

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

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

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

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

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

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

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

Выкидывают NFS. На нём большую скорость, тем более, на множестве мелких файлов не получите. Следующий этап - выкинуть винчестер NFS-сервера и подключить что-то побыстрее.


Хорошо бы посмотреть, а насколько I/O загружено на GPFS-сервере. подозреваю, что упираетесь уже там...



Тут - как удобнее... По факту - надо просто нечто, запускающее N процессов Лучше - на разных компьютерах, чтобы не толкаться в памяти, но в данном случае, думаю, это не принципиально.

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

интересная мысль.


Попробовав запустить только 16 нитей (вместо 32), занятость ядра возрасла до 93% (согласно top). Вы правы. Возможно имеет смысл использовать часть нитей для чтения, а часть для обработки.

Если какие-то тулзы, чтоб можно было посмотреть I/O загруженность на GPFS-сервере?

Каков общий объем файлов?

Посмотреть загрузку IO можно банально top'ом или более расширенно iostat'ом.