-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
gdalbuildvrt freezes at 90%... then gets killed #9212
Comments
How many files are indexed in the VRT? This may indeed be a RAM issue at the point where the VRT driver tries to generate the XML file if there are hundreds of thousands of files or more. The https://gdal.org/drivers/raster/gti.html driver + https://gdal.org/programs/gdaltindex.html#gdaltindex of the GDAL master branch (unreleased yet) might be what you need if insufficient RAM is indeed the issue |
ill give it a read. I currently input 735757 files |
…eaches 80% of RAM (fixes OSGeo#9212)
…eaches 80% of RAM (fixes OSGeo#9212)
…eaches 80% of RAM (fixes OSGeo#9212)
it was the ram. I tried on a machine with 128 RAM and it worked |
VRT serialization: emit a warning if RAM usage of XML serialization reaches 80% of RAM (fixes #9212)
I am trying to convert about 440GB of TIFFs in Geopackage in a docker container. For that i am making a VRT file from all found tifs in my volume folder using gdalbuild vrt. For some reason, the command goes up to 90%... then freezes and gets killed in a couple of hours without giving any ERROR message. The biggest volume of TIFFs that i converted successfully with this methode was around 150GB. Is this a problem with gdalbuildvrt or a memory problem ( in the sense that i dont have enough RAM ).
![Unbenannt](https://private-user-images.githubusercontent.com/118290996/303316920-5e647009-81b2-478a-bc04-4123d063632e.PNG?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MzkzNjE0MDUsIm5iZiI6MTczOTM2MTEwNSwicGF0aCI6Ii8xMTgyOTA5OTYvMzAzMzE2OTIwLTVlNjQ3MDA5LTgxYjItNDc4YS1iYzA0LTQxMjNkMDYzNjMyZS5QTkc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjUwMjEyJTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI1MDIxMlQxMTUxNDVaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT1mZjRkNDhiMDQ2ZDY5YzU4NjMxNTNlOGJiMDNiOWE2YmEwMDAyMWIzZGVhZTI2NmJjZGM0YmI0ZWVjODFkYWI1JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.z-_SwiLVVhfbG0KN9ajW6YGZc8-3ACHy3UTURVnnYYA)
This is the Console output of the command:
This is my Docker stats:
![memory](https://private-user-images.githubusercontent.com/118290996/303316999-9fb82085-d330-478c-af71-13767d583d23.PNG?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MzkzNjE0MDUsIm5iZiI6MTczOTM2MTEwNSwicGF0aCI6Ii8xMTgyOTA5OTYvMzAzMzE2OTk5LTlmYjgyMDg1LWQzMzAtNDc4Yy1hZjcxLTEzNzY3ZDU4M2QyMy5QTkc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjUwMjEyJTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI1MDIxMlQxMTUxNDVaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT1hZmVlMGMzZDZkY2ZlZDQxNmQzMTcwNzk0YTc0ZmI3ZjFmZmQwNDA4NTg4M2U2ZGJlOTk5ZTcyZjZjZjljNGQxJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.kj9OZg7vlJ67wSUfU_bKrXu9QQaJgqZpG5nBHDOhQIc)
In the meantime i will try a workaround to only convert around 150GB of TIFFS to Geopackage and then merge all Geopackages using ogr2ogr
The text was updated successfully, but these errors were encountered: