Threading OGR / GDAL menghasilkan pemanfaatan inti rendah


13

Saya mencoba untuk memproses beberapa data raster menggunakan ogr / gdal dan sepertinya saya tidak bisa mendapatkan pemanfaatan penuh dari semua core pada mesin saya. Ketika saya hanya menjalankan proses pada satu inti, saya mendapatkan utilisasi 100% dari inti itu. Ketika saya mencoba untuk memecah menjadi multicore (dalam contoh di bawah, dengan memotong x offset dan menempatkannya dalam antrian), saya mendapatkan pemanfaatan yang menyedihkan pada masing-masing 8 core saya. Sepertinya hanya menambah pemanfaatan hingga 100% di setiap inti (mis. 12,5% untuk masing-masing).

Saya khawatir bahwa menggunakan sumber data yang sama adalah hambatan, tapi kemudian saya menduplikasi file raster yang mendasari untuk setiap inti ... dan pemanfaatan inti masih omong kosong. Ini membuat saya percaya bahwa ogr atau gdal entah bagaimana berperilaku seperti sumber daya bersama bottleneck tapi saya tidak dapat menemukan apa pun online tentang itu. Bantuan apa pun akan sangat dihargai!

Ini adalah fungsi "pembantu" yang berjalan di dalam setiap utas Pekerja:

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()])

Tidak mungkin, tetapi apakah Anda memeriksa apakah memori menjadi hambatan?
lynxlynxlynx

@lynxlynxlynx - ya Memori jelas bukan hambatan. Sudah berusaha melacak hal ini sepanjang hari ... ini cukup aneh.
Maks

Mungkin saja driver raster yang Anda gunakan sama sekali tidak dirancang untuk dipanggil dari lebih dari satu utas sekaligus. Referensi: mail-archive.com/gdal-dev@lists.osgeo.org/msg07283.html
blah238

Jawaban:


10

BAIK. Itu adalah hari dalam hidupku bahwa aku tidak akan pernah kembali lagi. Ternyata masalahnya bukan pada kode yang saya posting di atas. Tidak apa-apa. Ternyata ini adalah kasus threading.Proses vs multiproses. Proses.

Seperti yang ditunjukkan dalam dokumentasi python :

Paket multi-pemrosesan menawarkan konkurensi lokal dan jarak jauh, secara efektif menuntun Global Interpreter Lock dengan menggunakan subproses alih-alih utas. Karena ini, modul multiprosesing memungkinkan programmer untuk memanfaatkan sepenuhnya beberapa prosesor pada mesin yang diberikan

Dengan demikian, threading. Benang untuk operasi intensif-IO, multiprosesing. Proses untuk operasi intensif CPU. Saya beralih ke multiprocessing. Proses dan semuanya berfungsi dengan baik.

Lihatlah tutorial ini untuk mempelajari cara menggunakan multiprocessing.Process


Saya hanya akan menyarankan itu, saya tidak yakin implementasi mana (ada juga implementasi pihak ke-3 ) yang Anda gunakan :) Saya baru-baru ini menggunakannya untuk mempercepat alat bayangan bangunan yang rapi di sini: Port “Memproduksi Bayangan Bangunan” Avenue kode ke ArcGIS 10
blah238

+1 Saya akan memposting bahwa Anda harus memiliki kata di milis GDAL-dev; tapi aku sekarang senang kamu tidak! Ini telah disemprotkan untuk referensi di masa mendatang.
MerseyViking

FWIW (mungkin tidak terlalu banyak), saya membaca di suatu tempat orang mengumpulkan dana untuk mencoba memperbaiki masalah kunci juru bahasa global (GIL). Saya pikir itu untuk 3.x.
canisrufus
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.