Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RedisCache#clear() calls KEYS [DATAREDIS-838] #1413

Closed
spring-projects-issues opened this issue May 22, 2018 · 1 comment
Closed

RedisCache#clear() calls KEYS [DATAREDIS-838] #1413

spring-projects-issues opened this issue May 22, 2018 · 1 comment
Assignees
Labels
status: superseded An issue that has been superseded by another

Comments

@spring-projects-issues
Copy link

Louis Morgan opened DATAREDIS-838 and commented

I'm not sure if this should be classed as a bug or not, so have filed as an Improvement.

Calling RedisCache#clear() results in a call to the Redis KEYS command, which you are advised not to use in production. Would it be possible to move this to use SCAN, at least when not calling a Redis cluster?

Some more context on the issue:

We recently moved from a Redis cluster to a single instance. As part of that move we replaced all calls to keys() in our code with calls to scan() based on performance issues we observed on a staging environment and the Redis docs:

Warning: consider KEYS as a command that should only be used in production environments with extreme care. It may ruin performance when it is executed against large databases. This command is intended for debugging and special operations, such as changing your keyspace layout. Don't use KEYS in your regular application code. If you're looking for a way to find keys in a subset of your keyspace, consider using SCAN or sets.

However, there were a few places in our code where we call RedisCache#clear() which we didn't realise uses KEYS under the hood. This resulted in a brief blip on our production environment because our Redis instance essentially locked up (100% CPU, no longer servicing other requests). The SLOWLOG suggested that KEYS was the culprit, which we traced back to a call to clear()


3 votes, 3 watchers

@mp911de
Copy link
Member

mp911de commented Mar 6, 2023

Fixed via #1721/#2051.

@mp911de mp911de closed this as not planned Won't fix, can't repro, duplicate, stale Mar 6, 2023
@mp911de mp911de added status: superseded An issue that has been superseded by another and removed type: enhancement A general enhancement labels Mar 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: superseded An issue that has been superseded by another
Projects
None yet
Development

No branches or pull requests

3 participants