Replies: 2 comments 1 reply
-
Hi @hrodmn -- are you running on Azure Postgres for Flexible Server? If so, you can enable pgBouncer and try to limit the number of actual database connections. Even if you're not running Flexible Server, setting up your own pgBouncer is probably the first thing to try. |
Beta Was this translation helpful? Give feedback.
1 reply
-
I wound up deploying my STAC services on AWS using eoAPI. The database/function arrangement is very robust - if you need to stand up a STAC API I highly recommend it. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I am running stac-fastapi with pgstac in a serverless Azure Function App. Most of the time this is working really well, but sometimes when too many requests get thrown at the API it chokes with database connection errors (e.g. 16 parallel processes that each send occasional GET requests).
The PostgreSQL database is running on Azure, too, and the
max_connections
parameter is set to 859. In the PostgreSQL logs I see this error:remaining connection slots are reserved for non-replication superuser connections
.I haven't seen anything published about deployment best practices so I wonder if anyone here has any suggestions! Is it a bad idea to run stac-fastapi as a serverless application? Is there a better way to set it up to take better advantage of pooled database connections?
Thanks in advance for any suggestions!
example API error log
Beta Was this translation helpful? Give feedback.
All reactions