Issue with RAM usage

[guillemc23]

We've been running TiTiler for a while now and we've seen this behavior both using the uvicorn and gunicorn approaches.

It seems as if the multiple workers are not properly liberating RAM, not sure if this is related to the way GDAL, rasterio or FastAPI handles the reading and closing of rasters, so I'm not sure if there are any environment variables that directly affect this. Has anyone experienced this as well?

This might be interesting as well, since the base image is already running Python 3.14 🤔 https://github.com/fastapi/fastapi/releases/tag/0.136.0

[vincentsarago]

can you describe the environment you are running your application on?

[guillemc23]

Hi Vincent!

We are running a custom version of TiTiler, which is basically base TiTiler with some other algorithms we added. This is built and ran with Docker using gunicorn as in here, but with 4 workers:

titiler/dockerfiles/Dockerfile

Line 30 in ed81bc6

CMD gunicorn -k uvicorn.workers.UvicornWorker ${MODULE_NAME}:${VARIABLE_NAME} --bind ${HOST}:${PORT} --workers ${WEB_CONCURRENCY}

We are not currently setting any of these variables in the docker-compose.yml, we're relying on default GDAL values:

titiler/docker-compose.yml

Lines 10 to 20 in ed81bc6

	# GDAL config
	- CPL_TMPDIR=/tmp
	- GDAL_CACHEMAX=75%
	- GDAL_INGESTED_BYTES_AT_OPEN=32768
	- GDAL_DISABLE_READDIR_ON_OPEN=EMPTY_DIR
	- GDAL_HTTP_MERGE_CONSECUTIVE_RANGES=YES
	- GDAL_HTTP_MULTIPLEX=YES
	- GDAL_HTTP_VERSION=2
	- PYTHONWARNINGS=ignore
	- VSI_CACHE=TRUE
	- VSI_CACHE_SIZE=536870912

The base image we are using to build our custom TiTiler instance is based on Python 3.14 (python:3.14-slim), but not on the GIL-free kernel referenced in the fastapi release above.

Hope this helps :-)