Redis CPU High-occupancy problem location processing

A project with Redis as a cache encounters a strange problem when it comes to release: The new Deployment software package has reached 100% CPU utilization on the REDIS server during stress testing. Then the fallback code, compared to the upcoming package and the old package differences, while running on the corresponding Redis server Info commandstats command to capture the packet analysis, found the following phenomenon:

As shown above two all commands performed by the Redis server within 1 minutes of deployment of the old package;

Here we can see clearly that the number of pings received by Redis within 1 minutes is approximately: 6237822-5903451=334371; What about the ping that Redis received within 1 minutes after the new package? As shown below:

The number of PING commands received by Redis within 1 minutes is: 33709828-33111344 = 598484;

By contrast, we found that Redis had achieved a 50% difference between the ping commands on the Redis server when the new package and the deployment of the old package were fairly similar to the other commands received. So what causes this problem to occur? In the Redis configuration we see the following two parameters: When the above two parameters are all set to true, it means that Jedis will send a ping command to detect whether the connection between Jedis and Redis server is normal when it obtains the connection and releases the connection. Comparing the two parameters in the different packages, it is found that the above two parameters are all set to true in the new package, while the above two values are set to false in the old package. The problem has been solved. However, if you set both of these to false to indicate that the connection between Jedis and Redis is no longer detected when getting the connection and releasing the connection, it is quite obvious that this is a rough practice So is there a way to send a ping every unit of time to detect the accessibility between the Jedis and the Redis server? Redis gives us this option, specifically configured as follows:testonborrow.rel=falsetestonreturn.rel=falsetimebetweenevictionrunsmillis=60000        -------Check idle connections periodically every 60 seconds minevictableidletimemillis=120000            ---------The minimum time value, in milliseconds, that the connection remains idle in the pool and is not reclaimed by the idle connection collector thread                      numtestsperevictionrun=-1                      ----------Idle connection scan, the maximum number of connections scanned at a time, typically set to-1, All scans are set so that you don't have to detect Jedis and redis every timeCan be reached, and by the way it improves the performance of the application. In addition: The idea of Redis location problem can be found in:http://blog.arganzheng.me/posts/redis-could-not-get-resource-from-pool.htmlhttp://caiguangguang.blog.51cto.com/1652935/1635752

Redis CPU High-occupancy problem location processing