Recently, I encountered this problem when optimizing cube.js. In fact, after checking the official documents later, the official also explained the problem.

main cause

Redis concurrent connection configuration (but it’s not simple. After testing, if the connection pool is not available and the connection is not enough, there will be a problem that the entire service is unavailable)

The official solution

Combine your actual user query request to configure the connection pool

• Reference configuration

CUBEJS_REDIS_POOL_MAX = 2000
CUBEJS_REDIS_POOL_MIN = 50
REDIS_URL = redis: //127.0.0.1:6379 // Reference connection, which can be combined with ioredis and redis client

• A reference to optimize the allocation of
  reasonable or try not to trigger the maximum number of connections, pressure tested, prone to extreme in some cases after being connected with a full, do not have the entire service (even after a connection release)
  specifically cube.js based generic- the connection pool to pool resources to check each release number, the number may be recommended through the configuration can be released as soon as possible, to avoid causing unavailable services can not
  use
  packages / cubejs-query-orchestrator / src / orchestrator / RedisPool.ts

const opts = {
            min,
            max,
            acquireTimeoutMillis: 5000,
            idleTimeoutMillis: 3000,
            numTestsPerEvictionRun: 300, // can be solved by configuration
            evictionRunIntervalMillis: 5000
};

Description

In the short term, the solution is to use a larger number of connection pools, and perform more pressure tests later, and see if the configuration can be added to the official code.