Skip to content

use startEvictionTimeProc() in config set maxmemory#10019

Merged
oranagra merged 3 commits intoredis:unstablefrom
soloestoy:prop-opt-1-config-set-maxmemory
Jan 4, 2022
Merged

use startEvictionTimeProc() in config set maxmemory#10019
oranagra merged 3 commits intoredis:unstablefrom
soloestoy:prop-opt-1-config-set-maxmemory

Conversation

@soloestoy
Copy link
Contributor

@soloestoy soloestoy commented Dec 28, 2021

This would mean that the effects of CONFIG SET maxmemory may not be visible once the command returns.
That could anyway happen since incremental eviction was added in redis 6.2 (see #7653)

We do this to fix one of the propagation bugs about eviction see #9890 and #10014.

@soloestoy soloestoy requested review from guybe7 and oranagra December 28, 2021 09:11
@soloestoy soloestoy force-pushed the prop-opt-1-config-set-maxmemory branch from 54261c5 to c889245 Compare December 28, 2021 09:12
We support incremental eviction now, and eviction should
only be performed before a command execution (in processCommand())
or in the time event proc. Eviction should be forbidden
during a command execution, see redis#9890 and redis#10014.
Copy link
Member

@oranagra oranagra left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in the past, i was hesitant to do that
i.e. rely on timers (cron / beforeSleep, future commands) to do that.
the reason was that i thought the caller may be issuing an INFO MEMORY, right after the CONFIG SET, and he expects to see the difference being applied.
this could be our tests, but also some actual users.

These days with the incremental eviction, i suppose this change doesn't break any concern that's not already broken, since anyway, the caller can't rely on the entire memory overhead to be evicted right away.

i.e. it is likely that the config change is a drastic one (e.g. from 5gb to 4gb), and we'll exit the eviction loop early.

unless of course, the user (or test) disabled the incremental eviction (i.e. maxmemory-eviction-tenacity).

i.e. some users or tests may have got bugs when this incremental eviction thing was introduced, and disabled it in order to use the new version of redis without solving this issue (now we break them)

@guybe7 @yossigo @madolson @JimB123 WDYT

@oranagra
Copy link
Member

for the record, we discussed this in a core-team meeting.
considered:

  1. respond with an error when conditions are wrong.
  2. delay the eviction only when the conditions are wrong.
  3. delay the eviction always.

this should also apply for config set appendonly
@soloestoy can you update that PR to handle both?
we decided on the last one.

@oranagra
Copy link
Member

on a second thought, maybe it's a better idea to handle appendonly in #10015 (related to fork, which that other PR deals with)
so i guess this one can be merged as is (with the small change Guy asked for)

@oranagra oranagra added release-notes indication that this issue needs to be mentioned in the release notes approval-needed Waiting for core team approval to be merged labels Jan 2, 2022
@oranagra
Copy link
Member

oranagra commented Jan 2, 2022

@redis/core-team please approve

@oranagra oranagra merged commit 2e1979a into redis:unstable Jan 4, 2022
@oranagra oranagra added the breaking-change This change can potentially break existing application label Jan 23, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approval-needed Waiting for core team approval to be merged breaking-change This change can potentially break existing application release-notes indication that this issue needs to be mentioned in the release notes

Projects

Archived in project

Development

Successfully merging this pull request may close these issues.

4 participants