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 2012年

@lynxlynxlynx-是的 内存绝对不是瓶颈。一直试图追踪这件事……这很奇怪。
2012年

可能是因为您设计的光栅驱动程序并非设计为一次只能从多个线程中调用。参考:mail-archive.com/gdal-dev@lists.osgeo.org/msg07283.html
blah238 2012年

Answers:


10

好。那是我生命中的一天,我再也不会回来了。原来问题不在我上面发布的代码中。很好 原来,这是threading.Thread与multiprocessing.Process的一种情况。

python文档中指出的:

多处理程序包同时提供本地和远程并发性,通过使用子进程而不是线程来有效地避开全局解释器锁。因此,多处理模块允许程序员充分利用给定机器上的多个处理器

因此,threading.Thread用于IO密集型操作,multiprocessing.Process用于CPU密集型操作。我切换到multiprocessing.Process,一切都很好。

查看本教程以了解如何使用multiprocessing.Process


我只是建议,我不确定您使用的是哪个实现(也有第三方的实现):)我最近使用它来加速此处的整洁建筑阴影工具:Port“ Producing Building Shadows” Avenue代码到ArcGIS 10
blah238

+1我正要发布,您应该在GDAL-dev邮件列表中写一个字;但我现在很高兴您没有!这已被遗弃以备将来参考。
MerseyViking

FWIW(可能不是很多),我读到有人在募集资金以尝试解决全球解释器锁定(GIL)问题。我认为它将适用于3.x。
canisrufus 2012年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.