1. 21 May, 2020 1 commit
  2. 20 May, 2020 2 commits
    • Oran Agra's avatar
      fix a rare active defrag edge case bug leading to stagnation · 88d71f47
      Oran Agra authored
      There's a rare case which leads to stagnation in the defragger, causing
      it to keep scanning the keyspace and do nothing (not moving any
      allocation), this happens when all the allocator slabs of a certain bin
      have the same % utilization, but the slab from which new allocations are
      made have a lower utilization.
      
      this commit fixes it by removing the current slab from the overall
      average utilization of the bin, and also eliminate any precision loss in
      the utilization calculation and move the decision about the defrag to
      reside inside jemalloc.
      
      and also add a test that consistently reproduce this issue.
      88d71f47
    • Oran Agra's avatar
      improve DEBUG MALLCTL to be able to write to write only fields. · 5d83e9e1
      Oran Agra authored
      also support:
        debug mallctl-str thread.tcache.flush VOID
      5d83e9e1
  3. 19 May, 2020 1 commit
  4. 18 May, 2020 2 commits
    • hujie's avatar
      fix clear USER_FLAG_ALLCOMMANDS flag in acl · edc1f7b1
      hujie authored
      in ACLSetUserCommandBit, when the command bit overflows, no operation
      is performed, so no need clear the USER_FLAG_ALLCOMMANDS flag.
      
      in ACLSetUser, when adding subcommand, we don't need to call
      ACLGetCommandID ahead since subcommand may be empty.
      edc1f7b1
    • ShooterIT's avatar
      Redis Benchmark: generate random test data · abff2640
      ShooterIT authored
      The function of generating random data is designed by antirez. See #7196.
      abff2640
  5. 16 May, 2020 1 commit
    • antirez's avatar
      Remove the client from CLOSE_ASAP list before caching the master. · 624742d9
      antirez authored
      This was broken in 1a7cd2c0: we identified a crash in the CI, what
      was happening before the fix should be like that:
      
      1. The client gets in the async free list.
      2. However freeClient() gets called again against the same client
         which is a master.
      3. The client arrived in freeClient() with the CLOSE_ASAP flag set.
      4. The master gets cached, but NOT removed from the CLOSE_ASAP linked
         list.
      5. The master client that was cached was immediately removed since it
         was still in the list.
      6. Redis accessed a freed cached master.
      
      This is how the crash looked like:
      
      === REDIS BUG REPORT START: Cut & paste starting from here ===
      1092:S 16 May 2020 11:44:09.731 # Redis 999.999.999 crashed by signal: 11
      1092:S 16 May 2020 11:44:09.731 # Crashed running the instruction at: 0x447e18
      1092:S 16 May 2020 11:44:09.731 # Accessing address: 0xffffffffffffffff
      1092:S 16 May 2020 11:44:09.731 # Failed assertion:  (:0)
      
      ------ STACK TRACE ------
      EIP:
      src/redis-server 127.0.0.1:21300(readQueryFromClient+0x48)[0x447e18]
      
      And the 0xffff address access likely comes from accessing an SDS that is
      set to NULL (we go -1 offset to read the header).
      624742d9
  6. 15 May, 2020 1 commit
    • antirez's avatar
      Cache master without checking of deferred close flags. · 1a7cd2c0
      antirez authored
      The context is issue #7205: since the introduction of threaded I/O we close
      clients asynchronously by default from readQueryFromClient(). So we
      should no longer prevent the caching of the master client, to later
      PSYNC incrementally, if such flags are set. However we also don't want
      the master client to be cached with such flags (would be closed
      immediately after being restored). And yet we want a way to understand
      if a master was closed because of a protocol error, and in that case
      prevent the caching.
      1a7cd2c0
  7. 14 May, 2020 6 commits
  8. 13 May, 2020 2 commits
  9. 12 May, 2020 2 commits
  10. 11 May, 2020 1 commit
    • Oran Agra's avatar
      fix redis 6.0 not freeing closed connections during loading. · 905e28ee
      Oran Agra authored
      This bug was introduced by a recent change in which readQueryFromClient
      is using freeClientAsync, and despite the fact that now
      freeClientsInAsyncFreeQueue is in beforeSleep, that's not enough since
      it's not called during loading in processEventsWhileBlocked.
      furthermore, afterSleep was called in that case but beforeSleep wasn't.
      
      This bug also caused slowness sine the level-triggered mode of epoll
      kept signaling these connections as readable causing us to keep doing
      connRead again and again for ll of these, which keep accumulating.
      
      now both before and after sleep are called, but not all of their actions
      are performed during loading, some are only reserved for the main loop.
      
      fixes issue #7215
      905e28ee
  11. 10 May, 2020 1 commit
  12. 09 May, 2020 3 commits
    • antirez's avatar
      Cluster: clarify we always resolve the sender. · 4387ba6a
      antirez authored
      4387ba6a
    • antirez's avatar
      Cluster: refactor ping/data delay handling. · 79de9d6c
      antirez authored
      79de9d6c
    • antirez's avatar
      Cluster: introduce data_received field. · 00a3bc43
      antirez authored
      We want to send pings and pongs at specific intervals, since our packets
      also contain information about the configuration of the cluster and are
      used for gossip. However since our cluster bus is used in a mixed way
      for data (such as Pub/Sub or modules cluster messages) and metadata,
      sometimes a very busy channel may delay the reception of pong packets.
      So after discussing it in #7216, this commit introduces a new field that
      is not exposed in the cluster, is only an internal information about
      the last time we received any data from a given node: we use this field
      in order to avoid detecting failures, claiming data reception of new
      data from the node is a proof of liveness.
      00a3bc43
  13. 07 May, 2020 1 commit
  14. 06 May, 2020 2 commits
  15. 05 May, 2020 8 commits
  16. 04 May, 2020 6 commits