[gdal-dev] GDAL_retile slowdown at next level
acangi
aca at ngi.be
Tue May 11 04:14:41 EDT 2010
Hello,
It looks like gdal_retile.py slows down when processing a new level of the
pyramid.
Source files : 8065 geotiffs orthophotos of 4000 x 4000 pixels, in total 400
GB.
Command : gdal_retile.py -targetDir pyramid/ -levels 12 -v -s_srs
/mnt/webgisdata/geoserver/config/3812.prj -ps 512 512 -r bilinear -co
"COMPRESS=JPEG" -co "INTERLEAVE=PIXEL" -tileIndex orthocol -tileIndexField
location /opt/geodata/ortholinks/*.tif
Level 0 was processed in 6 days (500000 files, 1 file is processed in 1
second, total 64 GB).
Level 1 starts processing : 1 file is processed in 5 minutes. As it'd take
me a year to finish the level, I stopped it.
Restarted with the same command and -pyramidOnly parameter
Level 1 was processed in 6 days (125000 files, 1 file is processed in 4
seconds, total 17 GB).
Level 2 starts processing : 1 file is processed in 3 minutes. It would take
2 monthes to finish this level.
I'll wait a little more to see the evolution and then stop the process
again, and restart it based on the level 1 files.
Any idea why it slows down like this ?
The source files and the output are on a CIFS fileserver, the computer
processing gdal_retile is a 4 CPU, 2.5 GB RAM. top says :
top - 10:12:57 up 7 days, 23:37, 1 user, load average: 1.00, 1.06, 1.09
Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie
Cpu(s): 1.2%us, 0.0%sy, 0.0%ni, 98.2%id, 0.0%wa, 0.0%hi, 0.0%si,
0.7%st
Mem: 2560220k total, 2506852k used, 53368k free, 21316k buffers
Swap: 2097144k total, 5496k used, 2091648k free, 949224k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
4913 ctiadmin 20 0 243m 163m 8064 D 6 6.5 283:36.06 python
Any idea appreciated,
Alain
--
View this message in context: http://osgeo-org.1803224.n2.nabble.com/GDAL-retile-slowdown-at-next-level-tp5034870p5034870.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
More information about the gdal-dev
mailing list