Нарізка OGR / GDAL призводить до низької експлуатації ядра


13

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

Я був стурбований тим, що використання одного і того ж джерела даних було вузьким місцем, але я потім копіював нижній растровий файл для кожного ядра ... і використання ядра все ще лайно. Це приводить мене до думки, що ogr чи gdal якось поводяться як загальний ресурс, але я нічого не можу знайти про це в Інтернеті. Будь-яка допомога буде дуже вдячна!

Це функція "помічник", яка працює всередині кожного потоку Worker:

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

ГАРАЗД. Це був день мого життя, до якого я більше ніколи не повернусь. Виявляється, проблема була не в коді, який я розмістив вище. Це абсолютно добре. Виявляється, це був випадок нарізання різьби. Thread vs. multiprocessing.Process.

Як зазначено в документації на пітон :

Багатопроцесорний пакет пропонує як локальну, так і віддалену одночасність, ефективно крокуючи глобальний блокнот інтерпретатора, використовуючи підпроцеси замість потоків. Завдяки цьому багатопроцесорний модуль дозволяє програмісту повністю використовувати декілька процесорів на даній машині

Таким чином, нарізка ниток. Нитка призначена для операцій з інтенсивним введенням, багатопроцесової обробки. Я перейшов на багатопроцесорний процес.Процес і все чудово працює.

Перегляньте цей підручник, щоб дізнатися, як використовувати багатопроцесорний процес


Я тільки збирався запропонувати це, я не був впевнений, яку реалізацію (є також сторонні реалізації ) ви використовуєте :) Я нещодавно використовував це для прискорення акуратного інструменту тіней для будівництва тут: Порт «Створення будівельних тіней» проспект код до ArcGIS 10
blah238

+1 я збирався опублікувати повідомлення про те, що ви повинні мати слово у списку розсилки GDAL-dev; але я радий, що ти цього не зробив! Це було виведено для подальшого використання.
MerseyViking

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