считайте несколько файлов с помощью многопроцессорной обработки

Question

считайте несколько файлов с помощью многопроцессорной обработки

Я должен считать некоторые очень огромные текстовые файлы (100 + Мбит), обработать каждый строки с regex и хранить данные в структуру. Моя структура наследовалась defaultdict, она имеет чтение (сам) метод, которые читают сам file_name файл.

Посмотрите на это очень простое (но не реальные) пример, я не использую regex, но я разделяю строки:


import multiprocessing
from collections import defaultdict

def SingleContainer():
    return list()

class Container(defaultdict):
    """
    this class store odd line in self["odd"] and even line in self["even"].
    It is stupid, but it's only an example. In the real case the class
    has additional methods that do computation on readen data.
    """
    def __init__(self,file_name):
        if type(file_name) != str:
            raise AttributeError, "%s is not a string" % file_name
        defaultdict.__init__(self,SingleContainer)
        self.file_name = file_name
        self.readen_lines = 0
    def read(self):
        f = open(self.file_name)
        print "start reading file %s" % self.file_name
        for line in f:
            self.readen_lines += 1
            values = line.split()
            key = {0: "even", 1: "odd"}[self.readen_lines %2]
            self[key].append(values)
        print "readen %d lines from file %s" % (self.readen_lines, self.file_name)

def do(file_name):
    container = Container(file_name)
    container.read()
    return container.items()

if __name__ == "__main__":
    file_names = ["r1_200909.log", "r1_200910.log"]
    pool = multiprocessing.Pool(len(file_names))
    result = pool.map(do,file_names)
    pool.close()
    pool.join()
    print "Finish"

В конце я должен присоединиться к каждому результаты в единственном Контейнере. Важно, чтобы порядок строк был сохранен. Мой подход является слишком медленным при возвращении значения. Лучшее решение? Я использую python 2.6 на Linux

5

python performance multiprocessing

задан Ruggero Turra 15 January 2010 в 20:30

3 ответа

Другие вопросы по тегам:

python performance multiprocessing

Похожие вопросы:

score 0 · Answer 1

Многопроцессор более подходит для процессов, ориентированных на CPU или Memory, поскольку время поиска вращательных приводов убивает производительность при переключении файлов. Либо загрузите файлы журналов в быструю флешку или какой-то диск памяти (физический или виртуальный) или отказываться от многопроцессора.

score 0 · Answer 2

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

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

Вы, вероятно, должны запускать эту программу несколько раз или в цикле, передавая другое значение на Multipressing.pool () каждый раз, начиная с 1 и переходом на количество сердечников. Время каждого пробега, и посмотри, какой счетчик работника делает лучше всего.

Результат будет зависеть от того, как CPU-интенсивный (в отличие от диска-интенсивной) ваша задача. Я бы не был удивлен, если бы 2 были лучше всего, если ваша задача около половины процессора и половины диска даже на 8-ядерной машине.

score 5 · Answer 3

Вы, вероятно, попали в две проблемы.

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

Во-вторых, вы попадаете на накладные расходы многопроцессорного модуля Python. Это на самом деле не использует потоки, но вместо этого запускают несколько процессов и сериализуют результаты через трубу. Это очень медленно для объемных данных - на самом деле, кажется, медленнее, чем работа, которую вы делаете в потоке (по крайней мере, в примере). Это реальная проблема, вызванная Гил.

Если я изменим do do (), чтобы вернуть ни одного вместо контейнера. Items () Отключить дополнительную копию данных, этот пример - это быстрее, чем один поток, если файлы уже кэшируют:

Две потоки: 0.36Elapsed 168% CPU

Один поток (заменить пункт. Как на карте): 0: 00.52Elapsed 98% CPU

К сожалению, проблема GIL является фундаментальным и не может быть обработана от внутри питона.