vCenter Server JDBC Connection Pool Max Size Configuration Lacks Upper Bound Enforcement

Direct answer

Use an external validation step (e.g., a pre‑start script or a configuration‑management hook) that reads the db.connection.pool.maxSize property from /etc/vmware-vpx/vcdb.properties (or the VCSA equivalent) and refuses to start the vpxd service if the value exceeds a calculated safe threshold. This provides the missing upper‑bound enforcement that vCenter does not apply internally.

Likely explanation

vCenter Server trusts the administrator‑provided value and does not compare it against PostgreSQL’s max_connections or the host’s file‑descriptor limit. Consequently, an overly large setting can cause PostgreSQL to reject new connections with "FATAL: sorry, too many clients already" or lead to "Too many open files" errors.

Confirmed facts

• Changes to db.connection.pool.maxSize require a restart of the vpxd service (or a full VCSA reboot) to take effect.
• PostgreSQL’s max_connections can be inspected with SHOW max_connections; in psql or from $VCENTER/postgresql.conf.
• The vmware user’s file‑descriptor limit is obtained via su - vmware -c 'ulimit -n'.
• Each JDBC connection typically consumes 1‑2 file descriptors (one for the socket, optionally one for SSL).

1. Determine PostgreSQL limit: Run SHOW max_connections; and note the value (e.g., 200).
2. Reserve connections for other services: Estimate the number of connections used by vCenter components (vpxd, vprobe, vmware-vpxd-svcs, etc.). A conservative reserve is 20‑30 connections.
3. Apply a safety margin: Subtract 10‑20% of the remaining connections to absorb transient spikes.
4. Check OS file‑descriptor limit: Get the vmware user’s ulimit -n (e.g., 4096). Divide by the expected descriptors per JDBC connection (use 2 for safety) to get the OS‑based ceiling.
5. Calculate the safe maximum: safeMax = min(PostgreSQL‑based limit, OS‑based limit).
6. Set the property: Edit /etc/vmware-vpx/vcdb.properties and set db.connection.pool.maxSize = safeMax.
7. Restart vCenter services: Run service-control --restart vpxd (or reboot the VCSA).
8. Verify the change: Confirm the new value in the properties file and ensure no "connection pool exhausted" messages appear in /var/log/vmware/vpxd/vpxd.log.

Real‑time monitoring options

• JMX: Connect JConsole or VisualVM to the vCenter JVM and inspect the HikariCP bean com.zaxxer.hikari:type=Pool,name=vcdb for ActiveConnections and IdleConnections.
• REST API (VCSA): Query GET /appliance/vcenter/database/status which returns activeConnections and idleConnections for the embedded vPostgres database.
• vSphere Client: Navigate to Monitor → Performance → DB Connection Pool Usage to view a chart of pool utilization.
• Direct PostgreSQL query: Execute SELECT count(*) FROM pg_stat_activity WHERE datname='VCDB'; to see the total number of connections currently used by the JDBC pool and other vCenter DB clients.

Missing diagnostic detail: To finalize the calculation, please provide the current PostgreSQL max_connections value and the vmware user’s file‑descriptor limit (ulimit -n). These numbers directly affect the safe maximum and may change the recommendation if they are lower than anticipated.