The current connection count continues to grow in my Elasticache Redis node

I am using Jedis in a tomcat web application to connect to the Elascticache Redis node. The application is used by hundreds of users in the daytime. I'm not sure if this is normal or not, but whenever I check the current count of connections with cloud indicators, I see that the current connections are growing without falling.

This is my Jedis pool configuration:

public static JedisPool getPool(){ if(pool == null){ JedisPoolConfig config = new JedisPoolConfig(); config.setMinIdle(5); config.setMaxIdle(35); config.setMaxTotal(1500); config.setMaxWaitMillis(3000); config.setTestOnBorrow(true); config.setTestWhileIdle(true); pool = new JedisPool(config, PropertiesManager.getInstance().getRedisServer()); } return pool; } 

and so I always use pool connections to execute redis commands:

  Jedis jedis = JedisUtil.getPool().getResource(); try{ //Redis commands } catch(JedisException e){ e.printStackTrace(); throw e; }finally{ if (jedis != null) JedisUtil.getPool().returnResource(jedis); } 

In this configuration, the number is currently greater than 200. Did I miss something that was supposed to cancel or kill unused connections? I set maxIdle to 35, and I expected the count to drop to 35 when traffic is very low, but this never happened.

+7
java tomcat amazon-elasticache redis jedis
source share
3 answers

we had the same problem. After studying a little further, we came across this (from the official redis documentation - http://redis.io/topics/clients ):

By default, the latest versions of Redis do not close the connection to the client if the client is inactive for many seconds: the connection will remain open forever.

By default, aws provides a timeout value of 0. Therefore, any connection that was initialized by your redis instance will be stored again, even if the connection initialized by your client does not work.

Create a new cache settings policy in aws with a timeout other than 0, and then you should be good

+7
source share

In the cache options group, you can edit timeout . The default value is 0, which leaves an idle connection in redis. If you set it to 100, it will disconnect standby connections for 100 seconds.

+3
source share

You can check the pool size using JMX. Activating an idict flow evictor is a good idea. You can do this by setting the timeBetweenEvictionRunsMillis parameter to JedisPoolConfig .

If you do not use transactions ( EXEC ) or blocking operations ( BLPOP , BRPOP ), you can stick to one connection if the number of connections is a problem for you. the lettuce client is thread safe with one connection

0
source share

All Articles