1. 24 Mar, 2023 2 commits
  2. 23 Mar, 2023 1 commit
  3. 21 Mar, 2023 3 commits
  4. 17 Mar, 2023 1 commit
  5. 14 Mar, 2023 2 commits
  6. 10 Mar, 2023 2 commits
  7. 08 Mar, 2023 26 commits
  8. 23 Feb, 2023 1 commit
    • Chen Tianjie's avatar
      Add CLIENT NO-TOUCH for clients to run commands without affecting LRU/LFU of keys (#11483) · 897c3d52
      Chen Tianjie authored
      
      
      When no-touch mode is enabled, the client will not touch LRU/LFU of the
      keys it accesses, except when executing command `TOUCH`.
      This allows inspecting or modifying the key-space without affecting their eviction.
      
      Changes:
      - A command `CLIENT NO-TOUCH ON|OFF` to switch on and off this mode.
      - A client flag `#define CLIENT_NOTOUCH (1ULL<<45)`, which can be shown
        with `CLIENT INFO`, by the letter "T" in the "flags" field.
      - Clear `NO-TOUCH` flag in `clearClientConnectionState`, which is used by `RESET`
        command and resetting temp clients used by modules.
      - Also clear `NO-EVICT` flag in `clearClientConnectionState`, this might have been an
        oversight, spotted by @madolson.
      - A test using `DEBUG OBJECT` command to verify that LRU stat is not touched when
        no-touch mode is on.
      Co-authored-by: default avatarchentianjie <chentianjie@alibaba-inc.com>
      Co-authored-by: default avatarMadelyn Olson <34459052+madolson@users.noreply.github.com>
      Co-authored-by: default avatarsundb <sundbcn@gmail.com>
      897c3d52
  9. 14 Feb, 2023 1 commit
    • guybe7's avatar
      SCAN/RANDOMKEY and lazy-expire (#11788) · fd82bccd
      guybe7 authored
      Starting from Redis 7.0 (#9890) we started wrapping everything a command
       propagates with MULTI/EXEC. The problem is that both SCAN and RANDOMKEY can
      lazy-expire arbitrary keys (similar behavior to active-expire), and put DELs in a transaction.
      
      Fix: When these commands are called without a parent exec-unit (e.g. not in EVAL or
      MULTI) we avoid wrapping their DELs in a transaction (for the same reasons active-expire
      and eviction avoids a transaction)
      
      This PR adds a per-command flag that indicates that the command may touch arbitrary
      keys (not the ones in the arguments), and uses that flag to avoid the MULTI-EXEC.
      For now, this flag is internal, since we're considering other solutions for the future.
      
      Note for cluster mode: if SCAN/RANDOMKEY is inside EVAL/MULTI it can still cause the
      same situation (as it always did), but it won't cause a CROSSSLOT because replicas and AOF
      do not perform slot checks.
      The problem with the above is mainly for 3rd party ecosystem tools that propagate commands
      from master to master, or feed an AOF file with redis-cli into a master.
      This PR aims to fix the regression in redis 7.0, and we opened #11792 to try to handle the
      bigger problem with lazy expire better for another release.
      fd82bccd
  10. 12 Feb, 2023 1 commit
    • Tian's avatar
      Reclaim page cache of RDB file (#11248) · 7dae142a
      Tian authored
      # Background
      The RDB file is usually generated and used once and seldom used again, but the content would reside in page cache until OS evicts it. A potential problem is that once the free memory exhausts, the OS have to reclaim some memory from page cache or swap anonymous page out, which may result in a jitters to the Redis service.
      
      Supposing an exact scenario, a high-capacity machine hosts many redis instances, and we're upgrading the Redis together. The page cache in host machine increases as RDBs are generated. Once the free memory drop into low watermark(which is more likely to happen in older Linux kernel like 3.10, before [watermark_scale_factor](https://lore.kernel.org/lkml/1455813719-2395-1-git-send-email-hannes@cmpxchg.org/) is introduced, the `low watermark` is linear to `min watermark`, and there'is not too much buffer space for `kswapd` to be wake up to reclaim memory), a `direct reclaim` happens, which means the process would stall to wait for memory allocation.
      
      # What the PR does
      The PR introduces a capability to reclaim the cache when the RDB is operated. Generally there're two cases, read and write the RDB. For read it's a little messy to address the incremental reclaim, so the reclaim is done in one go in background after the load is finished to avoid blocking the work thread. For write, incremental reclaim amortizes the work of reclaim so no need to put it into background, and the peak watermark of cache can be reduced in this way.
      
      Two cases are addresses specially, replication and restart, for both of which the cache is leveraged to speed up the processing, so the reclaim is postponed to a right time. To do this, a flag is added to`rdbSave` and `rdbLoad` to control whether the cache need to be kept, with the default value false.
      
      # Something deserve noting
      1. Though `posix_fadvise` is the POSIX standard, but only few platform support it, e.g. Linux, FreeBSD 10.0.
      2. In Linux `posix_fadvise` only take effect on writeback-ed pages, so a `sync`(or `fsync`, `fdatasync`) is needed to flush the dirty page before `posix_fadvise` if we reclaim write cache.
      
      # About test
      A unit test is added to verify the effect of `posix_fadvise`.
      In integration test overall cache increase is checked, as well as the cache backed by RDB as a specific TCL test is executed in isolated Github action job.
      7dae142a