Redis [QUESTION] [CSC] [Tracking] Pushing invalid messages consumes too much CPU on the server

Hi, @sundb @zuiderkwast @sjpotter, please help me look into this issue when you have time. thanks!

We are doing POC functional verification of CSC. We found that the server-side push of invalidation messages consumes a lot of CPU resources.

The CPU consumption of the three slave nodes (we connect the tracking connection only to the slave nodes) is about 2-3 times that of the master node.

Some details are as follows:

• Redis version: 6.0.9
• Redis Cluster info: 3 masters and 3 slaves
• Tracking mode: default
• The frequency of updating data on the server: updated once a day, qps 5.9w , lasts 17 seconds,
• Redis server cpu util:
• There are only 10 client machines(Application) in total, and the number of client connections to each redis server is only about 80.

Is this normal? Has Redis done any benchmarking on CSC?

We were concerned that it would consume too much CPU resources on the Redis server when there were many client machines using tracking.

Thanks~

Comment From: sundb

invalidate messages will grow in the following scenario: 1. too many clients, invalid messages are multiplied by the number of clients. 2. the keys change frequently, which means that the writes are far more than reads.

please check if you have these conditions.

Comment From: wp973

invalidate messages will grow in the following scenario:

1. too many clients, invalid messages are multiplied by the number of clients.
2. the keys change frequently, which means that the writes are far more than reads.

please check if you have these conditions.

Thansk for your reply! @sundb

We should be the first case, but there are only 10 client machines(Application) in total, and the number of client connections to each redis server is only about 80.

In actual applications, the number of client machines may reach dozens or even hundreds. In this case, is CSC still applicable?

Comment From: sundb

@wp973 from the info you gave we can see that each command would send (7.5/5.9) * 10 invalid messages, which too frequent, CSC is suitable for the scenario of less write and more read.

Comment From: wp973

@wp973 from the info you gave we can see that each command would send (7.5/5.9) * 10 invalid messages, which too frequent, CSC is suitable for the scenario of less write and more read.

Thansk for your reply! @sundb

I corrected: the data write frequency is: once a day, duration 17 seconds, qps 5.9w.

Our usage scenario is to read more and write less.

We only update data once a day, and each update lasts about 20 seconds, and the total number of updated keys is 1 million.

Comment From: sundb

@wp973 It feels like you're invalidating all of your keys, so I recommend turning tracking off first, and then turning it on after the operation is complete.

Comment From: wp973

@wp973 It feels like you're invalidating all of your keys

@sundb Yes, our scenario requires that most keys be updated every day (but only once a day). I think CSC is suitable for this scenario(write less and read more).

@wp973 It feels like you're invalidating all of your keys, so I recommend turning tracking off first, and then turning it on after the operation is complete.

If tracking is turned off, the client will not receive the invalidation message. Won't this be a problem?

Comment From: sundb

If tracking is turned off, the client will not receive the invalidation message. Won't this be a problem?

you also need to clear the local cache at the same time, and since most of the keys are invalid, the easiest way is to clear it.