1. 15 Sep, 2024 1 commit
  2. 13 Sep, 2024 2 commits
  3. 12 Sep, 2024 6 commits
    • Filipe Oliveira (Redis)'s avatar
      Optimize SSCAN command in case of listpack or intset encoding: avoid the usage... · f2f85ba3
      Filipe Oliveira (Redis) authored
      Optimize SSCAN command in case of listpack or intset encoding: avoid the usage of intermediate list. From 2N to N iterations (#13530)
      
      On SSCAN, in case of listpack and intset encoding we actually reply the
      entire set, and always reply with the cursor 0.
      
      For those cases, we don't need to accumulate the replies in a list and
      can completely avoid the overhead of list appending and then iterating
      over the list again -- meaning we do N iterations instead of 2N
      iterations over the SET and save intermediate memory as well.
      
      Preliminary benchmarks, `SSCAN set:100 0`, showcased an improvement of
      60% as visible bellow on a SET with 100 string elements (listpack
      encoded).
      f2f85ba3
    • Moti Cohen's avatar
      Add iterator capability to ebuckets DS (#13519) · c115c523
      Moti Cohen authored
      Add basic iterator API for ebuckets of start, next, nextBucket and stop.
      c115c523
    • Moti Cohen's avatar
      Correct spelling error at t_hash.c comment (#13540) · 65a87cb7
      Moti Cohen authored
      spell check error : ./src/t_hash.c:1141: RESOTRE ==> RESTORE
      65a87cb7
    • Moti Cohen's avatar
      HFE - Fix key ref by the hash on RENAME/MOVE/SWAPDB/RESTORE (#13539) · 9a89e32a
      Moti Cohen authored
      If the hash previously had HFEs (hash-fields with expiration) but later no longer
      does, the key ref in the hash might become outdated after a MOVE, COPY,
      RENAME or RESTORE operation. These commands maintain the key ref only
      if HFEs are present. That is, we can only be sure that key ref is valid as long as the
      hash has HFEs.
      9a89e32a
    • Oran Agra's avatar
      RED-129256, Fix TOUCH command from script in no-touch mode (#13512) · 610eb26c
      Oran Agra authored
      
      
      When a client in no-touch mode issues a TOUCH command on a key, the
      key’s access time should be updated, but in scripts, and module's
      RM_Call, it isn’t updated.
      Command proc should be matched to the executing client, not the current
      client.
      Co-authored-by: default avatarUdi Ron <udi@speedb.io>
      610eb26c
    • Steve's avatar
      Avoid cluster.nodes load corruption due to shard-id generation (#13468) · d265a614
      Steve authored
      
      
      PR #13428 doesn't fully resolve an issue where corruption errors can
      still occur on loading of cluster.nodes file - seen on upgrade where
      there were no shard_ids (from old Redis), 7.2.5 loading generated new
      random ones, and persisted them to the file before gossip/handshake
      could propagate the correct ones (or some other nodes unreachable).
      This results in a primary/replica having differing shard_id in the
      cluster.nodes and then the server cannot startup - reports corruption.
      
      This PR builds on #13428 by simply ignoring the replica's shard_id in
      cluster.nodes (if it exists), and uses the replica's primary's shard_id.
      Additional handling was necessary to cover the case where the replica
      appears before the primary in cluster.nodes, where it will first use a
      generated shard_id for the primary, and then correct after it loads the
      primary cluster.nodes entry.
      
      ---------
      Co-authored-by: default avatardebing.sun <debing.sun@redis.com>
      d265a614
  4. 11 Sep, 2024 1 commit
    • debing.sun's avatar
      Increment kvstore's non_empty_dicts only on first insert (#13528) · 2dd4cca3
      debing.sun authored
      
      
      Found by @oranagra 
      
      Currently, when the size of dict becomes 1, we do not check whether
      `delta` is positive or negative.
      As a result, `non_empty_dicts` is still incremented when the size of
      dict changes from 2 to 1.
      We should only increment `non_empty_dicts` when `delta` is positive, as
      this indicates the first time an element is inserted into the dict.
      
      ---------
      Co-authored-by: default avataroranagra <oran@redislabs.com>
      2dd4cca3
  5. 10 Sep, 2024 1 commit
    • Filipe Oliveira (Redis)'s avatar
      Optimize LREM, LPOS, LINSERT, LINDEX: Avoid N-1 sdslen() calls on listTypeEqual (#13529) · bcae7708
      Filipe Oliveira (Redis) authored
      This is a very easy optimization, that avoids duplicate computation of
      the object length for LREM, LPOS, LINSERT na LINDEX.
      
      We can see that sdslen takes 7.7% of the total CPU cycles of the
      benchmarks.
      
      Function Stack | CPU Time: Total | CPU Time: Self | Module | Function
      (Full) | Source File | Start Address
      -- | -- | -- | -- | -- | -- | --
      listTypeEqual | 15.50% | 2.346s | redis-server | listTypeEqual |
      t_list.c | 0x845dd
      sdslen | 7.70% | 2.300s | redis-server | sdslen | sds.h | 0x845e4
      
      Preliminary data showcases 4% improvement in the achievable ops/sec of
      LPOS in string elements, and 2% in int elements.
      bcae7708
  6. 09 Sep, 2024 1 commit
  7. 08 Sep, 2024 1 commit
    • Ozan Tezcan's avatar
      Fix flaky replication tests (#13518) · ac03e372
      Ozan Tezcan authored
      #13495 introduced a change to reply -LOADING while flushing existing db on a replica. Some of our tests are
       sensitive to this change and do no expect -LOADING reply.
      
      Fixing a couple of tests that fail time to time.
      ac03e372
  8. 06 Sep, 2024 1 commit
  9. 05 Sep, 2024 2 commits
  10. 04 Sep, 2024 4 commits
  11. 03 Sep, 2024 7 commits
    • debing.sun's avatar
      Avoid overhead of comparision function pointer calls in lpFind() (#13503) · de7f2f87
      debing.sun authored
      
      
      In #13279 (found by @filipecosta90), for custom lookups, we introduce a
      comparison function for `lpFind()` to compare entry, but it also
      introduces some overhead.
      
      To avoid the overhead of function pointer calls:
      1. Extract the lpFindCb() method into a lpFindCbInternal() method that
      is easier to inline.
      2. Use unlikely to annotate the comparison method, as can only success
      once.
      
      ---------
      Co-authored-by: default avatarOzan Tezcan <ozantezcan@gmail.com>
      de7f2f87
    • Filipe Oliveira (Redis)'s avatar
      changed addReplyHumanLongDouble to addReplyDouble in georadiusGeneric and geoposCommand (#13494) · fb8755a6
      Filipe Oliveira (Redis) authored
      # Summary 
      
      - Addresses https://github.com/redis/redis/issues/11565
      - Measured improvements of 30% and 37% on the simple use-case (GEOSEARCH
      and GEOPOS) (check
      https://github.com/redis/redis/pull/13494#issuecomment-2313668934), and
      of 66% on a dataset with >60M datapoints and pipeline 10 benchmark.
      fb8755a6
    • Meir Shpilraien (Spielrein)'s avatar
      Added new defrag API to allocate and free raw memory. (#13509) · d3d94ccf
      Meir Shpilraien (Spielrein) authored
      All the defrag allocations API expects to get a value and replace it, leaving the old value untouchable.
      In some cases a value might be shared between multiple keys, in such cases we can not simply replace
      it when the defrag callback is called.
      
      To allow support such use cases, the PR adds two new API's to the defrag API:
      
      1. `RM_DefragAllocRaw` - allocate memory base on a given size.
      2. `RM_DefragFreeRaw` - Free the given pointer.
      
      Those API's avoid using tcache so they operate just like `RM_DefragAlloc` but allows the user to split
      the allocation and the memory free operations into two stages and control when those happen.
      
      In addition the PR adds new API to allow the module to receive notifications when defrag start and end: `RM_RegisterDefragCallbacks`
      Those callbacks are the same as `RM_RegisterDefragFunc` but promised to be called and the start
      and the end of the defrag process.
      d3d94ccf
    • Filipe Oliveira (Redis)'s avatar
      Created specific SMEMBERS command logic which avoids sinterGenericCommand, and... · 00a8e72c
      Filipe Oliveira (Redis) authored
      
      Created specific SMEMBERS command logic which avoids sinterGenericCommand, and minimizes processing and memory overhead (#13499)
      
      This PR introduces a dedicated implementation for the SMEMBERS command
      that avoids using the more generalized sinterGenericCommand function.
      By tailoring the logic specifically for SMEMBERS, we reduce unnecessary
      processing and memory overheads that were previously incurred by
      handling more complex cases like set intersections.
      
      ---------
      Co-authored-by: default avatardebing.sun <debing.sun@redis.com>
      00a8e72c
    • Filipe Oliveira (Redis)'s avatar
      Optimize the HELLO command reply (#13490) · a31b516e
      Filipe Oliveira (Redis) authored
      # Overall improvement
      
      TBD ( current is approximately 6% on the achievable ops/sec), coming
      from:
      
      - In case of no module we can skip 1.3% CPU cycles on dict Iterator
      creation/deletion
      - Use addReplyBulkCBuffer instead of addReplyBulkCString to avoid
      runtime strlen overhead within HELLO reply on string constants.
      
      ## Optimization 1: In case of no module we can skip 1.3% CPU cycles on
      dict Iterator creation/deletion.
      
      ## Optimization 2: Use addReplyBulkCBuffer instead of
      addReplyBulkCString to avoid runtime strlen overhead within HELLO reply
      on string constants.
      a31b516e
    • cyy-tag's avatar
      Fixed variable parameter formatting issues in serverPanic function (#13504) · c77b8f45
      cyy-tag authored
      
      
      Currently aeApiPoll panic does not record error code information. Added
      variable parameter formatting to _serverPanic to fix the issue
      
      ---------
      Co-authored-by: default avataryingyin.chen <15816602944@163.com>
      c77b8f45
    • Ozan Tezcan's avatar
      Reply LOADING on replica while flushing the db (#13495) · a7afd1d2
      Ozan Tezcan authored
      On a full sync, replica starts discarding existing db. If the existing 
      db is huge and flush is happening synchronously, replica may become 
      unresponsive. 
      
      Adding a change to yield back to event loop while flushing db on 
      a replica. Replica will reply -LOADING in this case. Note that while 
      replica is loading the new rdb, it may get an error and start flushing
      the partial db. This step may take a long time as well. Similarly, 
      replica will reply -LOADING in this case. 
      
      To call processEventsWhileBlocked() and reply -LOADING, we need to do:
      - Set connSetReadHandler() null not to process further data from the master
      - Set server.loading flag
      - Call blockingOperationStarts()
      
      rdbload() already does these steps and calls processEventsWhileBlocked()
      while loading the rdb. Added a new call rdbLoadWithEmptyFunc() which 
      accepts callback to flush db before loading rdb or when an error 
      happens while loading. 
      
      For diskless replication, doing something similar and calling emptyData()
      after setting required flags.
      
      Additional changes:
      - Allow `appendonly` config change during loading. 
       Config can be changed while loading data on startup or on replication 
       when slave is loading RDB. We allow config change command to update 
       `server.aof_enabled` and then lazily apply config change after loading
       operation is completed.
       
       - Added a test for `replica-lazy-flush` config
      a7afd1d2
  12. 29 Aug, 2024 1 commit
    • Oran Agra's avatar
      testsuite --dump-logs works on servers started before the test (#13500) · 3fcddfb6
      Oran Agra authored
      so far ./runtest --dump-logs used work for servers started within the
      test proc.
      now it'll also work on servers started outside the test proc scope.
      the downside is that these logs can be huge if they served many tests
      and not just the failing one.
      but for some rare failures, we rather have that than nothing.
      this feature isn't enabled y default, but is used by our GH actions.
      3fcddfb6
  13. 28 Aug, 2024 1 commit
  14. 26 Aug, 2024 1 commit
  15. 21 Aug, 2024 1 commit
  16. 20 Aug, 2024 2 commits
    • Zihao Lin's avatar
      Improve GETRANGE command behavior (#12272) · 6ceadfb5
      Zihao Lin authored
      
      
      Fixed the issue about GETRANGE and SUBSTR command
      return unexpected result caused by the `start` and `end` out of
      definition range of string.
      
      ---
      ## break change
      Before this PR, when negative `end` was out of range (i.e., end <
      -strlen), we would fix it to 0 to get the substring, which also resulted
      in the first character still being returned for this kind of out of
      range.
      After this PR, we ensure that `GETRANGE` returns an empty bulk when the
      negative end index is out of range.
      
      Closes #11738
      
      ---------
      Co-authored-by: default avatardebing.sun <debing.sun@redis.com>
      6ceadfb5
    • judeng's avatar
      improve performance for scan command when matching data type (#12395) · 7f0a7f0a
      judeng authored
      Move the TYPE filtering to the scan callback so that avoided the
      `lookupKey` operation. This is the follow-up to #12209 . In this thread
      we introduced two breaking changes:
      1. we will not attempt to do lazy expire (delete) a key that was
      filtered by not matching the TYPE (like we already do for MATCH
      pattern).
      2. when the specified key TYPE filter is an unknown type, server will
      reply a error immediately instead of doing a full scan that comes back
      empty handed.
      7f0a7f0a
  17. 19 Aug, 2024 2 commits
    • Meir Shpilraien (Spielrein)'s avatar
      Avoid used_memory contention when update from multiple threads. (#13431) · 3264deb2
      Meir Shpilraien (Spielrein) authored
      The PR attempt to avoid contention on the `used_memory` global variable
      when allocate or free memory from multiple threads at the same time.
      
      Each time a thread is allocating or releasing a memory, it needs to
      update the `used_memory` global variable. This update might cause a
      contention when done aggressively from multiple threads.
      
      ### The solution
      
      Instead of having a single global variable that need to be updated from
      multiple thread. We create an array of used_memory, each entry in the
      array is updated by a single thread and the main thread summarizes all
      the values to accumulate the memory usage.
      
      This solution, though reduces the contention between threads on updating
      the `used_memory` global variable, it adds work to the main thread that
      need to summarize all the entries at the `used_memory` array. To avoid
      increasing the work done by the main thread by too much, we limit the
      size of the used memory array to 16. This means that up to 16 threads
      can run without any contention between them. If there are more than 16
      threads, we will reuse entries on the used_memory array, in this case we
      might still have contention between threads, but it will be much less
      significant.
      
      Notice, that in order to really avoid contention, the entries in the
      `used_memory` array must reside on different cache lines. To achieve
      that we create a struct with padding such that its size will be exactly
      cache_line size. In addition we make sure the address of the
      `used_memory` array will be aligned to cache_line size.
      
      ### Benchmark
      
      Some benchmark shows improvement (up to 15%):
      
      | Test Case |Baseline unstable (median obs. +- std.dev)|Comparison
      test_used_memory_per_thread_array (median obs. +- std.dev)|% change
      (higher-better)| Note |
      
      |-------------------------------------------------------------------------------|------------------------------------------|--------------------------------------------------------------------:|------------------------|------------------------------------|
      |memtier_benchmark-1key-list-100-elements-lrange-all-elements | 92657 +-
      2.0% (2 datapoints) | 101445|9.5% |IMPROVEMENT |
      |memtier_benchmark-1key-list-1K-elements-lrange-all-elements | 14965 +-
      1.3% (2 datapoints) | 16296|8.9% |IMPROVEMENT |
      |memtier_benchmark-1key-set-10-elements-smembers-pipeline-10 | 431019 +-
      5.2% (2 datapoints) | 461039|7.0% |waterline=5.2%. IMPROVEMENT |
      |memtier_benchmark-1key-set-100-elements-smembers | 74367 +- 0.0% (2
      datapoints) | 80190|7.8% |IMPROVEMENT |
      |memtier_benchmark-1key-set-1K-elements-smembers | 11730 +- 0.4% (2
      datapoints) | 13519|15.3% |IMPROVEMENT |
      
      
      Full results:
      
      | Test Case |Baseline unstable (median obs. +- std.dev)|Comparison
      test_used_memory_per_thread_array (median obs. +- std.dev)|% change
      (higher-better)| Note |
      
      |-------------------------------------------------------------------------------|------------------------------------------|--------------------------------------------------------------------:|------------------------|------------------------------------|
      |memtier_benchmark-10Mkeys-load-hash-5-fields-with-1000B-values | 88613
      +- 1.0% (2 datapoints) | 88688|0.1% |No Change |
      
      |memtier_benchmark-10Mkeys-load-hash-5-fields-with-1000B-values-pipeline-10
      | 124786 +- 1.2% (2 datapoints) | 123671|-0.9% |No Change |
      |memtier_benchmark-10Mkeys-load-hash-5-fields-with-100B-values | 122460
      +- 1.4% (2 datapoints) | 122990|0.4% |No Change |
      
      |memtier_benchmark-10Mkeys-load-hash-5-fields-with-100B-values-pipeline-10
      | 333384 +- 5.1% (2 datapoints) | 319221|-4.2% |waterline=5.1%.
      potential REGRESSION|
      |memtier_benchmark-10Mkeys-load-hash-5-fields-with-10B-values | 137354
      +- 0.3% (2 datapoints) | 138759|1.0% |No Change |
      
      |memtier_benchmark-10Mkeys-load-hash-5-fields-with-10B-values-pipeline-10
      | 401261 +- 4.3% (2 datapoints) | 398524|-0.7% |No Change |
      |memtier_benchmark-1Mkeys-100B-expire-use-case | 179058 +- 0.4% (2
      datapoints) | 180114|0.6% |No Change |
      |memtier_benchmark-1Mkeys-10B-expire-use-case | 180390 +- 0.2% (2
      datapoints) | 180401|0.0% |No Change |
      |memtier_benchmark-1Mkeys-1KiB-expire-use-case | 175993 +- 0.7% (2
      datapoints) | 175147|-0.5% |No Change |
      |memtier_benchmark-1Mkeys-4KiB-expire-use-case | 165771 +- 0.0% (2
      datapoints) | 164434|-0.8% |No Change |
      |memtier_benchmark-1Mkeys-bitmap-getbit-pipeline-10 | 931339 +- 2.1% (2
      datapoints) | 929487|-0.2% |No Change |
      |memtier_benchmark-1Mkeys-generic-exists-pipeline-10 | 999462 +- 0.4% (2
      datapoints) | 963226|-3.6% |potential REGRESSION |
      |memtier_benchmark-1Mkeys-generic-expire-pipeline-10 | 905333 +- 1.4% (2
      datapoints) | 896673|-1.0% |No Change |
      |memtier_benchmark-1Mkeys-generic-expireat-pipeline-10 | 885015 +- 1.0%
      (2 datapoints) | 865010|-2.3% |No Change |
      |memtier_benchmark-1Mkeys-generic-pexpire-pipeline-10 | 897115 +- 1.2%
      (2 datapoints) | 887544|-1.1% |No Change |
      |memtier_benchmark-1Mkeys-generic-scan-pipeline-10 | 451103 +- 3.2% (2
      datapoints) | 465571|3.2% |potential IMPROVEMENT |
      |memtier_benchmark-1Mkeys-generic-touch-pipeline-10 | 996809 +- 0.6% (2
      datapoints) | 984478|-1.2% |No Change |
      |memtier_benchmark-1Mkeys-generic-ttl-pipeline-10 | 979570 +- 1.7% (2
      datapoints) | 958752|-2.1% |No Change |
      
      |memtier_benchmark-1Mkeys-hash-hget-hgetall-hkeys-hvals-with-100B-values
      | 180888 +- 0.5% (2 datapoints) | 182295|0.8% |No Change |
      
      |memtier_benchmark-1Mkeys-hash-hmget-5-fields-with-100B-values-pipeline-10
      | 717881 +- 1.0% (2 datapoints) | 724814|1.0% |No Change |
      |memtier_benchmark-1Mkeys-hash-transactions-multi-exec-pipeline-20 |
      1055447 +- 0.4% (2 datapoints) | 1065836|1.0% |No Change |
      |memtier_benchmark-1Mkeys-lhash-hexists | 164332 +- 0.1% (2 datapoints)
      | 163636|-0.4% |No Change |
      |memtier_benchmark-1Mkeys-lhash-hincbry | 171674 +- 0.3% (2 datapoints)
      | 172737|0.6% |No Change |
      |memtier_benchmark-1Mkeys-list-lpop-rpop-with-100B-values | 180904 +-
      1.1% (2 datapoints) | 179467|-0.8% |No Change |
      |memtier_benchmark-1Mkeys-list-lpop-rpop-with-10B-values | 181746 +-
      0.8% (2 datapoints) | 182416|0.4% |No Change |
      |memtier_benchmark-1Mkeys-list-lpop-rpop-with-1KiB-values | 182004 +-
      0.7% (2 datapoints) | 180237|-1.0% |No Change |
      |memtier_benchmark-1Mkeys-load-hash-5-fields-with-1000B-values | 105191
      +- 0.9% (2 datapoints) | 105058|-0.1% |No Change |
      
      |memtier_benchmark-1Mkeys-load-hash-5-fields-with-1000B-values-pipeline-10
      | 150683 +- 0.9% (2 datapoints) | 153597|1.9% |No Change |
      |memtier_benchmark-1Mkeys-load-hash-hmset-5-fields-with-1000B-values |
      104122 +- 0.7% (2 datapoints) | 105236|1.1% |No Change |
      |memtier_benchmark-1Mkeys-load-list-with-100B-values | 149770 +- 0.9% (2
      datapoints) | 150510|0.5% |No Change |
      |memtier_benchmark-1Mkeys-load-list-with-10B-values | 165537 +- 1.9% (2
      datapoints) | 164329|-0.7% |No Change |
      |memtier_benchmark-1Mkeys-load-list-with-1KiB-values | 113315 +- 0.5% (2
      datapoints) | 114110|0.7% |No Change |
      |memtier_benchmark-1Mkeys-load-stream-1-fields-with-100B-values | 131201
      +- 0.7% (2 datapoints) | 129545|-1.3% |No Change |
      
      |memtier_benchmark-1Mkeys-load-stream-1-fields-with-100B-values-pipeline-10
      | 352891 +- 2.8% (2 datapoints) | 348338|-1.3% |No Change |
      |memtier_benchmark-1Mkeys-load-stream-5-fields-with-100B-values | 104386
      +- 0.7% (2 datapoints) | 105796|1.4% |No Change |
      
      |memtier_benchmark-1Mkeys-load-stream-5-fields-with-100B-values-pipeline-10
      | 227593 +- 5.5% (2 datapoints) | 218783|-3.9% |waterline=5.5%.
      potential REGRESSION|
      |memtier_benchmark-1Mkeys-load-string-with-100B-values | 167552 +- 0.2%
      (2 datapoints) | 170282|1.6% |No Change |
      |memtier_benchmark-1Mkeys-load-string-with-100B-values-pipeline-10 |
      646888 +- 0.5% (2 datapoints) | 639680|-1.1% |No Change |
      |memtier_benchmark-1Mkeys-load-string-with-10B-values | 174891 +- 0.7%
      (2 datapoints) | 174382|-0.3% |No Change |
      |memtier_benchmark-1Mkeys-load-string-with-10B-values-pipeline-10 |
      749988 +- 5.1% (2 datapoints) | 769986|2.7% |waterline=5.1%. No Change |
      |memtier_benchmark-1Mkeys-load-string-with-1KiB-values | 155929 +- 0.1%
      (2 datapoints) | 156387|0.3% |No Change |
      |memtier_benchmark-1Mkeys-load-zset-with-10-elements-double-score |
      92241 +- 0.2% (2 datapoints) | 92189|-0.1% |No Change |
      |memtier_benchmark-1Mkeys-load-zset-with-10-elements-int-score | 114328
      +- 1.3% (2 datapoints) | 113154|-1.0% |No Change |
      |memtier_benchmark-1Mkeys-string-get-100B | 180685 +- 0.2% (2
      datapoints) | 180359|-0.2% |No Change |
      |memtier_benchmark-1Mkeys-string-get-100B-pipeline-10 | 991291 +- 3.1%
      (2 datapoints) | 1020086|2.9% |No Change |
      |memtier_benchmark-1Mkeys-string-get-10B | 181183 +- 0.3% (2 datapoints)
      | 177868|-1.8% |No Change |
      |memtier_benchmark-1Mkeys-string-get-10B-pipeline-10 | 1032554 +- 0.8%
      (2 datapoints) | 1023120|-0.9% |No Change |
      |memtier_benchmark-1Mkeys-string-get-1KiB | 180479 +- 0.9% (2
      datapoints) | 182215|1.0% |No Change |
      |memtier_benchmark-1Mkeys-string-get-1KiB-pipeline-10 | 979286 +- 0.9%
      (2 datapoints) | 989888|1.1% |No Change |
      |memtier_benchmark-1Mkeys-string-mget-1KiB | 121950 +- 0.4% (2
      datapoints) | 120996|-0.8% |No Change |
      |memtier_benchmark-1key-geo-60M-elements-geodist | 179404 +- 1.0% (2
      datapoints) | 181232|1.0% |No Change |
      |memtier_benchmark-1key-geo-60M-elements-geodist-pipeline-10 | 1023797
      +- 0.5% (2 datapoints) | 1014980|-0.9% |No Change |
      |memtier_benchmark-1key-geo-60M-elements-geohash | 180808 +- 1.2% (2
      datapoints) | 180606|-0.1% |No Change |
      |memtier_benchmark-1key-geo-60M-elements-geohash-pipeline-10 | 1056458
      +- 1.6% (2 datapoints) | 1040050|-1.6% |No Change |
      |memtier_benchmark-1key-geo-60M-elements-geopos | 181808 +- 0.2% (2
      datapoints) | 175945|-3.2% |potential REGRESSION |
      |memtier_benchmark-1key-geo-60M-elements-geopos-pipeline-10 | 1038180 +-
      3.4% (2 datapoints) | 1033005|-0.5% |No Change |
      |memtier_benchmark-1key-geo-60M-elements-geosearch-fromlonlat | 142614
      +- 0.3% (2 datapoints) | 144259|1.2% |No Change |
      |memtier_benchmark-1key-geo-60M-elements-geosearch-fromlonlat-bybox |
      141008 +- 0.4% (2 datapoints) | 139602|-1.0% |No Change |
      
      |memtier_benchmark-1key-geo-60M-elements-geosearch-fromlonlat-pipeline-10
      | 560698 +- 0.8% (2 datapoints) | 548806|-2.1% |No Change |
      |memtier_benchmark-1key-list-10-elements-lrange-all-elements | 166132 +-
      0.9% (2 datapoints) | 170259|2.5% |No Change |
      |memtier_benchmark-1key-list-100-elements-lrange-all-elements | 92657 +-
      2.0% (2 datapoints) | 101445|9.5% |IMPROVEMENT |
      |memtier_benchmark-1key-list-1K-elements-lrange-all-elements | 14965 +-
      1.3% (2 datapoints) | 16296|8.9% |IMPROVEMENT |
      |memtier_benchmark-1key-pfadd-4KB-values-pipeline-10 | 264156 +- 0.2% (2
      datapoints) | 262582|-0.6% |No Change |
      |memtier_benchmark-1key-set-10-elements-smembers | 138916 +- 1.7% (2
      datapoints) | 138016|-0.6% |No Change |
      |memtier_benchmark-1key-set-10-elements-smembers-pipeline-10 | 431019 +-
      5.2% (2 datapoints) | 461039|7.0% |waterline=5.2%. IMPROVEMENT |
      |memtier_benchmark-1key-set-10-elements-smismember | 173545 +- 1.1% (2
      datapoints) | 173488|-0.0% |No Change |
      |memtier_benchmark-1key-set-100-elements-smembers | 74367 +- 0.0% (2
      datapoints) | 80190|7.8% |IMPROVEMENT |
      |memtier_benchmark-1key-set-100-elements-smismember | 155682 +- 1.6% (2
      datapoints) | 151367|-2.8% |No Change |
      |memtier_benchmark-1key-set-1K-elements-smembers | 11730 +- 0.4% (2
      datapoints) | 13519|15.3% |IMPROVEMENT |
      |memtier_benchmark-1key-set-200K-elements-sadd-constant | 181070 +- 1.1%
      (2 datapoints) | 180214|-0.5% |No Change |
      |memtier_benchmark-1key-set-2M-elements-sadd-increasing | 166364 +- 0.1%
      (2 datapoints) | 166944|0.3% |No Change |
      |memtier_benchmark-1key-zincrby-1M-elements-pipeline-1 | 46071 +- 0.6%
      (2 datapoints) | 44979|-2.4% |No Change |
      |memtier_benchmark-1key-zrank-1M-elements-pipeline-1 | 48429 +- 0.4% (2
      datapoints) | 49265|1.7% |No Change |
      |memtier_benchmark-1key-zrem-5M-elements-pipeline-1 | 48528 +- 0.4% (2
      datapoints) | 48869|0.7% |No Change |
      |memtier_benchmark-1key-zrevrangebyscore-256K-elements-pipeline-1 |
      100580 +- 1.5% (2 datapoints) | 101782|1.2% |No Change |
      |memtier_benchmark-1key-zrevrank-1M-elements-pipeline-1 | 48621 +- 2.0%
      (2 datapoints) | 48473|-0.3% |No Change |
      |memtier_benchmark-1key-zset-10-elements-zrange-all-elements | 83485 +-
      0.6% (2 datapoints) | 83095|-0.5% |No Change |
      
      |memtier_benchmark-1key-zset-10-elements-zrange-all-elements-long-scores
      | 118673 +- 0.8% (2 datapoints) | 118006|-0.6% |No Change |
      |memtier_benchmark-1key-zset-100-elements-zrange-all-elements | 19009 +-
      1.1% (2 datapoints) | 19293|1.5% |No Change |
      |memtier_benchmark-1key-zset-100-elements-zrangebyscore-all-elements |
      18957 +- 0.5% (2 datapoints) | 19419|2.4% |No Change |
      
      |memtier_benchmark-1key-zset-100-elements-zrangebyscore-all-elements-long-scores|
      171693 +- 0.5% (2 datapoints) | 172432|0.4% |No Change |
      |memtier_benchmark-1key-zset-1K-elements-zrange-all-elements | 3566 +-
      0.6% (2 datapoints) | 3672|3.0% |No Change |
      |memtier_benchmark-1key-zset-1M-elements-zcard-pipeline-10 | 1067713 +-
      0.4% (2 datapoints) | 1071550|0.4% |No Change |
      |memtier_benchmark-1key-zset-1M-elements-zrevrange-5-elements | 169195
      +- 0.7% (2 datapoints) | 169620|0.3% |No Change |
      |memtier_benchmark-1key-zset-1M-elements-zscore-pipeline-10 | 914338 +-
      0.2% (2 datapoints) | 905540|-1.0% |No Change |
      |memtier_benchmark-2keys-lua-eval-hset-expire | 88346 +- 1.7% (2
      datapoints) | 87259|-1.2% |No Change |
      |memtier_benchmark-2keys-lua-evalsha-hset-expire | 103273 +- 1.2% (2
      datapoints) | 102393|-0.9% |No Change |
      |memtier_benchmark-2keys-set-10-100-elements-sdiff | 15418 +- 10.9%
      UNSTABLE (2 datapoints) | 14369|-6.8% |UNSTABLE (very high variance) |
      |memtier_benchmark-2keys-set-10-100-elements-sinter | 83601 +- 3.6% (2
      datapoints) | 82508|-1.3% |No Change |
      |memtier_benchmark-2keys-set-10-100-elements-sunion | 14942 +- 11.2%
      UNSTABLE (2 datapoints) | 14001|-6.3% |UNSTABLE (very high variance) |
      |memtier_benchmark-2keys-stream-5-entries-xread-all-entries | 75938 +-
      0.4% (2 datapoints) | 76565|0.8% |No Change |
      |memtier_benchmark-2keys-stream-5-entries-xread-all-entries-pipeline-10
      | 120781 +- 1.1% (2 datapoints) | 119142|-1.4% |No Change |
      3264deb2
    • debing.sun's avatar
      Fix a race condition issue in the cache_memory of functionsLibCtx (#13476) · 6c648928
      debing.sun authored
      This is a missing of the PR https://github.com/redis/redis/pull/13383.
      We will call `functionsLibCtxClear()` in bio, so we shouldn't touch
      `curr_functions_lib_ctx` in it.
      6c648928
  18. 16 Aug, 2024 1 commit
    • debing.sun's avatar
      Fix incorrect lag due to trimming stream via XTRIM command (#13473) · 2b88db90
      debing.sun authored
      ## Describe
      When using the `XTRIM` command to trim a stream, it does not update the
      maximal tombstone (`max_deleted_entry_id`). This leads to an issue where
      the lag calculation incorrectly assumes that there are no tombstones
      after the consumer group's last_id, resulting in an inaccurate lag.
      
      The reason XTRIM doesn't need to update the maximal tombstone is that it
      always trims from the beginning of the stream. This means that it
      consistently changes the position of the first entry, leading to the
      following scenarios:
      
      1) First entry trimmed after maximal tombstone:
      If the first entry is trimmed to a position after the maximal tombstone,
      all tombstones will be before the first entry, so they won't affect the
      consumer group's lag.
      
      2) First entry trimmed before maximal tombstone:
      If the first entry is trimmed to a position before the maximal
      tombstone, the maximal tombstone will not be updated.
      
      ## Solution
      Therefore, this PR optimizes the lag calculation by ensuring that when
      both the consumer group's last_id and the maximal tombstone are behind
      the first entry, the consumer group's lag is always equal to the number
      of remaining elements in the stream.
      
      Supplement to PR https://github.com/redis/redis/pull/13338
      2b88db90
  19. 14 Aug, 2024 1 commit
  20. 11 Aug, 2024 1 commit
    • Moti Cohen's avatar
      On HDEL last field with expiry, update global HFE DS (#13470) · 806459f4
      Moti Cohen authored
      Hash field expiration is optimized to avoid frequent update global HFE DS for
      each field deletion. Eventually active-expiration will run and update or remove
      the hash from global HFE DS gracefully. Nevertheless, statistic "subexpiry"
      might reflect wrong number of hashes with HFE to the user if HDEL deletes
      the last field with expiration in hash (yet there are more fields without expiration).
      
      Following this change, if HDEL the last field with expiration in the hash then
      take care to remove the hash from global HFE DS as well.
      806459f4
  21. 08 Aug, 2024 2 commits