Многопоточность OGR / GDAL приводит к низкому использованию ядра


13

Я пытаюсь обработать некоторые растровые данные, используя ogr / gdal, и я не могу получить полное использование всех ядер на моей машине. Когда я запускаю процесс только на одном ядре, я получаю 100% -ное использование этого ядра. Когда я пытаюсь разделить на многоядерные (в приведенном ниже примере, разбивая смещения по x и помещая их в очередь), я получаю жалкое использование на каждом из моих 8 ядер. Похоже, что это добавляет до 100% загрузки на каждое ядро ​​(например, 12,5% на каждое).

Я был обеспокоен тем, что использование одного и того же источника данных было узким местом, но затем я продублировал базовый растровый файл для каждого ядра ... и использование ядра по-прежнему дерьмо. Это наводит меня на мысль, что ogr или gdal как-то ведут себя как общий ресурс с узким местом, но я не могу найти в Интернете ничего об этом. Любая помощь приветствуется!

Это «вспомогательная» функция, которая запускается внутри каждого рабочего потока:

def find_pixels_intersect_helper(datasource, bounds_wkt, x_min, x_max):
    bounds = ogr.CreateGeometryFromWkt(bounds_wkt)
    rows_to_write = []
    for x_offset in range(x_min, x_max):
        for y_offset in range(datasource.RasterYSize):
            pxl_bounds_wkt = pix_to_wkt(datasource, x_offset, y_offset)
            pxl_bounds = ogr.CreateGeometryFromWkt(pxl_bounds_wkt)
            if pxl_bounds.Intersect(bounds):
                rows_to_write.append(['%s_%s' % (x_offset, y_offset), pxl_bounds.Centroid().ExportToWkt()])

Вряд ли, но вы проверили, является ли память узким местом?
lynxlynxlynx

@lynxlynxlynx - да. Память определенно не является узким местом. Я пытался разыскать эту штуку весь день ... это довольно странно.
Макс

Может случиться так, что используемый вами растровый драйвер просто не предназначен для одновременного вызова из нескольких потоков. Ссылка: mail-archive.com/gdal-dev@lists.osgeo.org/msg07283.html
blah238

Ответы:


10

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

Как указано в документации по Python :

Многопроцессорный пакет предлагает как локальный, так и удаленный параллелизм, эффективно обойдя глобальную блокировку интерпретатора, используя подпроцессы вместо потоков. Благодаря этому многопроцессорный модуль позволяет программисту полностью использовать несколько процессоров на данном компьютере.

Таким образом, Threading .Thread для операций с интенсивным вводом-выводом, многопроцессорными. Процесс предназначен для операций с интенсивным использованием процессора. Я перешел на многопроцессорность. Процесс и все прекрасно работает.

Ознакомьтесь с этим руководством, чтобы узнать, как использовать многопроцессорность. Процесс


Я просто собирался предположить, что я не был уверен, какую реализацию (есть также сторонние реализации ) вы использовали :) Я использовал это недавно, чтобы ускорить использование инструмента аккуратных теней здесь: Порт «Proising Building Shadows» Avenue код для ArcGIS 10
blah238

+1 Я собирался написать, что у вас должно быть слово в списке рассылки GDAL-dev; но теперь я рад, что ты этого не сделал! Это было спрятано для дальнейшего использования.
MerseyViking

FWIW (вероятно, не очень), я читал где-то, что люди собирают средства, чтобы попытаться решить глобальную проблему блокировки интерпретатора (GIL). Я думаю, что это будет для 3.x.
canisrufus
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.