Многопоточность в ArcGIS с Python - PullRequest
Новая
       6

Многопоточность в ArcGIS с Python

4 голосов
/ 04 февраля 2011

У меня есть скрипт на python, который прекрасно работает, когда запускается сам по себе. Основываясь на жестко закодированном входном каталоге, он сканирует все файлы .mdb и помещает их в список, а затем просматривает их все в цикле for. Каждая итерация включает в себя несколько ограничений таблицы, объединений, запросов и т. Д.

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

Все, что я имею отношение к моему основному сценарию: 

indir = "D:\\basil\\input"
mdblist = createDeepMdbList(indir)
for infile in mdblist:
    processMdb(infile)

Также выполняется безупречно при последовательном выполнении.

Я пытался использовать Parallel Python: 

ppservers = ()
job_server = pp.Server(ppservers=ppservers)

inputs = tuple(mdblist)
functions = (preparePointLayer, prepareInterTable, jointInterToPoint,\
          prepareDataTable, exportElemTables, joinDatatoPoint, exportToShapefile)
modules = ("sys", "os", "arcgisscripting", "string", "time")

fn = pp.Template(job_server, processMdb, functions, modules)
jobs = [(input, fn.submit(input)) for input in inputs]

Ему удается создать 8 процессов, 8 объектов геопроцессора ... и затем происходит сбой.

Я не экспериментировал со встроенными инструментами многопоточности Python, но надеялся, что какое-то руководство просто вызовет до 8 процессов, проходящих через очередь, представленную mdblist. Ни в коем случае нельзя пытаться записать или прочитать какие-либо файлы несколькими процессами одновременно. Чтобы сделать вещи временно проще, я также удалил все свои инструменты регистрации из-за этой проблемы; Я запускал этот сценарий достаточно раз, чтобы знать, что он работает, за исключением 4 файлов ввода 4104, которые имеют немного разные форматы данных.

Совет? Мудрость при попытке многопоточности скриптов Arc Python?

Ответы [ 2 ]

5 голосов
/ 21 февраля 2011

Думаю, я поделюсь тем, что сработало для меня и моего опыта.

Использование обратного порта многопроцессорного модуля (code.google.com/p/python-multiprocessing) в соответствии с комментарием Джо работало хорошо,Мне пришлось изменить несколько вещей в моем сценарии, чтобы иметь дело с локальными / глобальными переменными и ведением журнала.

Основной сценарий теперь: 

if __name__ == '__main__':

    indir = r'C:\basil\rs_Rock_and_Sediment\DVD_Data\testdir'
    mdblist = createDeepMdbList(indir)

    processes = 6  # set num procs to use here
    pool = multiprocessing.Pool(processes)

    pool.map(processMdb, mdblist)

Общее время увеличилось с ~ 36 часов до ~8 с использованием 6 процессов.

Некоторые проблемы, с которыми я столкнулся, заключались в том, что при использовании отдельных процессов они обращаются к различным стекам памяти и полностью удаляют глобальные переменные.Для этого могут использоваться очереди, но я не реализовал это, поэтому все просто объявляется локально.

Кроме того, поскольку pool.map может принимать только один аргумент, каждая итерация должна создавать, а затем удалять объект геопроцессора, а невозможность создавать 8 gp и передавать доступный для каждой итерации.Каждая итерация занимает около минуты, поэтому создание ее за пару секунд не имеет большого значения, но она складывается.Я не проводил никаких конкретных тестов, но на самом деле это может быть хорошей практикой, поскольку любой, кто работал с Arcgis и python, будет знать, что сценарии резко замедляются, чем дольше активен геопроцессор (например, один из моих сценариев использовался одним израбочий, который перегрузил ввод и оценки времени до завершения, перешел с 50 часов после 1 часа работы до 350 часов после работы в течение ночи до 800 часов после работы 2 дня ... он был отменен и ввод ограничен).

Надеюсьэто помогает всем, кто ищет многопроцессорную работу с большими возможностями ввода :).Следующий шаг: рекурсивные, многопроцессорные добавления!

0 голосов
/ 30 мая 2011

Я сравнил вышеуказанные методы в той же функции. результат: 

Starting pp with 1 workers
Time elapsed:  4.625 s

Starting pp with 2 workers
Time elapsed:  2.43700003624 s

Starting pp with 4 workers
Time elapsed:  2.42100000381 s

Starting pp with 8 workers
Time elapsed:  2.375 s

Starting pp with 16 workers
Time elapsed:  2.43799996376 s

Starting mul_pool with 1 p
Time elapsed:  5.31299996376 s

Starting mul_pool with 2
Time elapsed:  3.125 s

Starting mul_pool with 4
Time elapsed:  3.56200003624 s

Starting mul_pool with 8
Time elapsed:  4.5 s

Starting mul_pool with 16
Time elapsed:  5.92199993134 s
...