During the RasterSources benchmark https://github.com/pomadchin/vlm-performance/ on EMR we received no performance improvements with GDAL usage. On the contrary, it created more complexity in jobs configuration. Without tuning GDAL_CAHEMAX options and wo (for warp operations), EMR nodes are dying / hanging and => tasks are failing. This is also can be the problem of the GDAL 2.3 usage on yarn and according to OSGeo/gdal@5351335 GDAL doesn't respect cgroups. But it is unclear how yarn limits resources, it may be not using cgroups to limit CPU / RAM and this can be useless in this case.
Related to https://github.com/azavea/raster-foundry-platform/issues/743
and to https://github.com/azavea/geotrellis/issues/68
During the RasterSources benchmark https://github.com/pomadchin/vlm-performance/ on EMR we received no performance improvements with GDAL usage. On the contrary, it created more complexity in jobs configuration. Without tuning
GDAL_CAHEMAXoptions andwo(for warp operations), EMR nodes are dying / hanging and => tasks are failing. This is also can be the problem of the GDAL 2.3 usage onyarnand according to OSGeo/gdal@5351335 GDAL doesn't respectcgroups. But it is unclear howyarnlimits resources, it may be not usingcgroupsto limit CPU / RAM and this can be useless in this case.Related to https://github.com/azavea/raster-foundry-platform/issues/743
and to https://github.com/azavea/geotrellis/issues/68