[gdal-dev] RE: Memory Error in _gdal.Band_ReadRaster(*args, **kwargs)

[Greg Coats]

You said you have 8 GB RAM, and gdal_translate was using only 2 GB  
RAM, and your specific question was "Do I need to set some settings  
to speed things up?". Yes, you should increase the amount of RAM  
gdal_translate makes available to GDAL_CACHEMAX. For example,  
"gdal_translate --config GDAL_CACHEMAX 4000 " followed by the rest of  
the gdal_translate command. In your message you have "--config  
GDAL_CACHEMAX 4000-v", but there needs to be a space after "4000" and  
before "-v".
I have successfully used gdal_merge.py and gdal_translate to create  
GeoTIFF files as large as 142 GB, under Unix based Mac OS X, on a  
computer with only 3 GB RAM.
Greg

On Aug 16, 2009, at 4:00 PM, Paul Meems wrote:
> Thanks Greg for your help about speeding things up.
> But speed is the least of my problems.
> I wouldn't mind waiting 72 hours if it gets the job done.
> But even with this statement:
> gdal_retile --config GDAL_CACHEMAX 4000-v -s_srs EPSG:28992 -of ECW  
> -ps 17335 16000 -targetDir tiles large.ecw
>
> I get the Memory error.
>
> Do you also have any suggestion on that. Would be very much  
> appreciated.
>
> Thanks,
> Paul
>
> 2009/8/14 Greg Coats <gregcoats at mac.com>
> It is my understanding that the default is
> gdal_translate --config GDAL_CACHEMAX 40 ...
> which equates to 40 MB of memory.
> If you want to allow gdal_translate to use say 2 GB of memory for  
> GDAL_CACHEMAX, enter
> gdal_translate --config GDAL_CACHEMAX 2000 ...
> In my experience, increasing GDAL_CACHEMAX substantially speeds up  
> gdal_translate processing.
> Greg
>
> On Aug 14, 2009, at 4:08 PM, Paul Meems wrote:
>
> I also noticed both gdal_translate and gdal_retile not use the full  
> potential of my hardware. I'm running Vista 64Bit on a AMD3 2.6Ghz  
> quadcore with 8GB RAM and only 2-2.5GB RAM was used by  
> gdal_translate, leaving more than 5 GB free and only 35-55% of my  
> CPU was used. Do I need to set some settings to speed things up?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090816/de1e7b90/attachment.html