Параллельное сопоставление регулярных выражений в среде DFS с использованием pthreads - PullRequest
0 голосов
/ 23 ноября 2010

Я пытаюсь распараллелить grep для университетского проекта.Я работаю над предположением, что создание большего количества потоков при фактическом сопоставлении регулярных выражений будет неэффективным: они будут обрабатывать данные быстрее, чем их можно прочитать с диска.Однако я работаю над кластером MPI, который использует систему Luster DFS, которая позволяет распределять данные между несколькими пулами хранения.

Я надеялся как-то использовать это, используя преимущества нескольких дисков, уменьшаяузкое место, созданное вводом / выводом жесткого диска.После некоторого начального тестирования я не могу найти решение, которое максимизирует DFS.

Я пробовал:

  1. Большой, один файл, чередующийся по нескольким OST.Каждый поток читает фрагменты данных размером с размер полосы (например, размер полосы / OST == размер чтения потока).Мое намерение состояло в том, чтобы каждый поток считывал данные из другого OST (кроме случаев перекрытия / границы).
  2. Несколько файлов меньшего размера, каждый из которых чередуется со своим собственным OST.Каждый поток читает полный файл, но каждый файл находится в отдельном OST.

В каждом случае мало, если нет ускорения.Я надеялся получить разумное ускорение (максимум в 2 раза было бы неплохо).

Стоит ли беспокоиться из-за узких мест ввода / вывода?

Как использовать преимущества DFSпри написании кода C?Я пытался прочитать данные из смещений, которые соответствуют размеру полосы, а также из файлов, которые находятся на разных OST и (я полагаю), на разных дисках.

Есть ли способ реализовать масштабируемую, параллельнуюgrep / regex matcher?

Ответы [ 2 ]

0 голосов
/ 23 ноября 2010

Ваша интуиция о том, как распараллелить эту проблему, кажется правильной, но я предполагаю, что в вашей реализации есть что-то, что неожиданно сериализует ваши обращения к диску.Grep будет привязан к вводу / выводу, и вы должны увидеть значительное ускорение, если вы заставите каждую систему в вашем кластере работать с локальными данными.

Вам нужно будет рассмотреть детали того, какдоступ к файлам через MPI осуществляется из системы Luster.Похоже, программный стек фактически сериализует все ваши обращения к диску, поэтому вы не можете воспользоваться распределенной FS.Или ваши клиенты могут обращаться к неправильному фрагменту файла для узла, на котором они находятся.

Как использовать преимущества DFS при написании кода C?

Если вы используете стандартные файловые операции POSIX, вам не повезло.Они не предоставляют достаточно информации, чтобы облегчить эту задачу.Вот почему распределенные системы хранения и обработки файлов записываются как

0 голосов
/ 23 ноября 2010

Это скорее расширенный комментарий, чем ответ ...

Вы пытаетесь написать параллельный grep или пытаетесь написать grep, который работает с различными параллельными данными?Я могу прочитать ваш вопрос, чтобы предположить, что вы думаете об одном или обоих.Если я прав (учтите, что обычно я ошибаюсь, когда пытаюсь интерпретировать вопросы), я предлагаю вам сначала разделить две проблемы и решить одну, а затем добавить другую.

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

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

Если ваш сценарий - написать параллельный grep, то этоПрограмма, которая использует несколько процессорных ядер при запуске, это, вероятно, еще более интересная (то есть сложная) проблема.Поскольку grep работает путем построения FA, а FA часто моделируются как графы, и поскольку графы (если они удовлетворяют некоторым критериям) можно разложить на подграфы, это, вероятно, выполнимо - вам просто нужно распараллелить построениеFA, порождает темы для подграфов и собирает результаты.Я полагаю, что распределение нагрузки будет затруднено.

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

Теперь, чтобы дать несколько плохих ответов на ваши вопросы.

  • Должен ли я беспокоиться оУзкие места ввода / вывода?-- Да, черт возьми.Вы измерили производительность grep на достаточно хорошем уровне, чтобы определить, какие пропорции времени настенных часов тратятся на различных его этапах, включая построение ТВС, чтение входных файлов и т. Д.grep - очень зрелый продукт, на который было потрачено много усилий по оптимизации, поэтому вы поставили перед собой жесткую задачу.Вы также измерили характеристики вашей кластерной файловой системы и время взаимодействия между потоками, такого рода вещи.
  • Как использовать преимущества DFS при написании кода C?- Не могу вам помочь, но я бы подумал, что API файловой системы обеспечивает необходимые функции;вы, кажется, пытаетесь обратиться непосредственно к аппаратному обеспечению диска.
  • Есть ли способ реализовать масштабируемое параллельное сопоставление grep / regex?- Я уверен, что есть, но вы студент, разве вы не проверили возможности и подводные камни перед началом этого проекта?
...