[MapServer-users] Mapcache - postgresql dimensions causing HUGE number of open db connections
Tim Kempisty
timothy.kempisty at noaa.gov
Wed Mar 27 08:28:20 PDT 2024
Mapcache folks,
This is a technical question about the Mapcache connection pool and how postgreql dimensions are implemented.
I have a big mapcache WMS with several hundred layers defined. Most of them have a postgresql dimension that reports back a list of available timestamps for these layers. When we are under load, I end up with a couple thousand database connections all coming from Mapcache. They're only lightweight dimension queries... it's just a LOT of connections hanging open. I'm looking for the upper bound on the number of these connections.
Looking at the Mapcache source code... I see a hard coded max_list_size = 10 in connection_pool.c. I assume that means any one mapcache process/thread is allowed to keep up to ten network connections open at one time.
dimension_pg.c seems to get its connections from this pool. Other connections use this pool though, right? Like the source URLs?
So if I have Mapcache running as an Apache module, and if Apache can launch up to 256 threads... I could be on the hook for up to 2560 connections sitting open (until the threads die off / time out.) Is my understanding correct?
It also looks like dimension_pg uses prepared statements on the db server. That would probably break a connection pooler like PgBouncer. So my options for managing the number of postgresql connections are:
1. Setting an obscene max_connections limit in postgresql.conf, allowing my mapcache role to consume a lot of them.
2. Reducing the number of Apache threads in mpm_event (At the risk of impacting general Apache performance)
3. Using the fastcgi version of Mapcache, and limiting the number of mapcache fcgi processes
4. Reducing max_list_size in connection_pool.c, which might impact performance.
Am I on the right track here?
-Tim
More information about the MapServer-users
mailing list