FATAL error: Remaining connection slots are reserved for non-replication superuser connections

[ahagopian_coj]

Hello!  Our datastore has been running at 100% CPU.  When checking the logs I keep getting this error: "FATAL: Remaining connection slots are reserved for non-replication superuser connections".  Has anyone come across this?  Why would datastore reserve connection slots?

Any ideas welcome!  I am at my whit's end with the datastore CPU usage.  I have a ticket in with ESRI but they don't know either.

[mattkramer]

The internal database keeps like 5 connections for internal processes, you can't get around these, but you can increase the max number of connections by using the changedbproperties command line tool on the data store machine. Documentation for this can be found here:
ArcGIS Data Store utility reference—Portal for ArcGIS | Documentation for ArcGIS Enterprise

The more connections you have, the more resources your data store will pull, so you will need to probably figure out why your CPU is maxed out (and maybe check RAM too) before making this update.

[ahagopian_coj]

Describedatastore shows 9 connections but the ESRI tech says I should have 0 connections which makes no sense to me.  Our settings allow up to 150 connections.  I told him that we need to have at least 2 connections for the GIS server for Portal but he just reiterated that there should be no connections. So when I came across the error in the logs I wonder if that was contributing to our 100% CPU usage.

[mattkramer]

Data store connections open and close very quickly, and the describedatastore only returns the current number of connections. You can have 150 1 second and 0 the next. Additionally, opening a map can open multiple connections, depending on the amount of data that is getting requested to satisfy that operation. 1 connection does not mean 1 user. Opening task manager on the data store machine is one way to better figure out where the CPU usage is coming from too.

[jcarlson]

We see this happen on occasion. It depends on where the connections are coming from. For instance, if I edit a hosted feature layer from QGIS or via Python, for whatever reason those connections stay "live" for much longer, especially if there is an error during the edit.

I've had it happen where I get the same message, and it usually coincides with a script debugging session or making edits from Q. Does any of that apply to your situation?

[ahagopian_coj]

Where do you see the "live" connection?  I do edit the Workforce layer in the DataStore daily using Python. Any suggestions for killing the "live" connection?