Zimbra SSDB resource pool limits

[ghen]

Hi

Does anyone here have zimbraSSDBResourcePoolSize and/or zimbraSSDBResourcePoolTimeout set to non-zero values?

We are experiencing occasional connection leaks from Zimbra towards the ephemeral database (SSDB/Redis), where sometimes new connections get created in bursts, which are never closed again. Eventually leading to resource exhaustion on the database side.

The above attributes are supposed to help, but I'm finding only very little documentation on them, let alone guidance. And Support isn't helping much, either.

(According to the Zimbra SSDBEphemeralStoreExtension source code, the underlying JedisPool parameters are maxTotal and maxWaitMillis. No other Jedis tunables are exposed.)

[JDunphy]

if it's zero then it's unlimited (-1) which isn't a great design given how they handle exceptions.

Code: Select all

            Config zimbraConf = Provisioning.getInstance().getConfig();

            int poolSize = zimbraConf.getSSDBResourcePoolSize();
            if (poolSize == 0) {
                poolConfig.setMaxTotal(-1);
            } else {
                poolConfig.setMaxTotal(poolSize);

I indexed the repository via: https://deepwiki.com/Zimbra/zm-ssdb-ephemeral-store to query various scenarios.

The JedisResourceWithRetry class destroys and recreates the entire connection pool on any JedisException SSDBEphemeralStore.java:314-321 :

Code: Select all

pool.destroy();  
pool = getPool(url);  
return jedisMethod();

That aggressive recreation could cause connection storms with large pool sizes.

zimbraSSDBResourcePoolSize

Code: Select all

// Recommended starting values based on typical workloads:  
// Small deployment: 10-20 connections  
// Medium deployment: 50-100 connections    
// Large deployment: 200-500 connections

zimbraSSDBResourcePoolTimeout

Code: Select all

// Recommended timeout: 5000-10000 milliseconds (5-10 seconds)  
// This prevents indefinite blocking and allows graceful degradation

Note: Above recommendations are LLM generated and not my own.

HTH,

Jim