1. 14 May, 2020 2 commits
  2. 12 May, 2020 1 commit
  3. 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
  4. 05 May, 2020 2 commits
  5. 02 May, 2020 2 commits
    • hwware's avatar
    • zhenwei pi's avatar
      Support setcpuaffinity on linux/bsd · 1a0deab2
      zhenwei pi authored
      Currently, there are several types of threads/child processes of a
      redis server. Sometimes we need deeply optimise the performance of
      redis, so we would like to isolate threads/processes.
      
      There were some discussion about cpu affinity cases in the issue:
      https://github.com/antirez/redis/issues/2863
      
      
      
      So implement cpu affinity setting by redis.conf in this patch, then
      we can config server_cpulist/bio_cpulist/aof_rewrite_cpulist/
      bgsave_cpulist by cpu list.
      
      Examples of cpulist in redis.conf:
      server_cpulist 0-7:2      means cpu affinity 0,2,4,6
      bio_cpulist 1,3           means cpu affinity 1,3
      aof_rewrite_cpulist 8-11  means cpu affinity 8,9,10,11
      bgsave_cpulist 1,10-11    means cpu affinity 1,10,11
      
      Test on linux/freebsd, both work fine.
      Signed-off-by: default avatarzhenwei pi <pizhenwei@bytedance.com>
      1a0deab2
  6. 29 Apr, 2020 2 commits
    • antirez's avatar
      Comment clearly why we moved some code in #6623. · d2a6c5ff
      antirez authored
      d2a6c5ff
    • srzhao's avatar
      fix pipelined WAIT performance issue. · 4024bc7e
      srzhao authored
      If client gets blocked again in `processUnblockedClients`, redis will not send
      `REPLCONF GETACK *` to slaves untill next eventloop, so the client will be
      blocked for 100ms by default(10hz) if no other file event fired.
      
      move server.get_ack_from_slaves sinppet after `processUnblockedClients`, so
      that both the first WAIT command that puts client in blocked context and the
      following WAIT command processed in processUnblockedClients would trigger
      redis-sever to send `REPLCONF GETACK *`, so that the eventloop would get
      `REPLCONG ACK <reploffset>` from slaves and unblocked ASAP.
      4024bc7e
  7. 28 Apr, 2020 1 commit
    • Oran Agra's avatar
      hickup, re-fix dictEncObjKeyCompare · 9a3dab0a
      Oran Agra authored
      come to think of it, in theory (not in practice), getDecodedObject can
      return the same original object with refcount incremented, so the
      pointer comparision in the previous commit was invalid.
      so now instead of checking the encoding, we explicitly check the
      refcount.
      9a3dab0a
  8. 27 Apr, 2020 3 commits
  9. 25 Apr, 2020 1 commit
  10. 24 Apr, 2020 1 commit
    • antirez's avatar
      LCS -> STRALGO LCS. · 8a7f255c
      antirez authored
      STRALGO should be a container for mostly read-only string
      algorithms in Redis. The algorithms should have two main
      characteristics:
      
      1. They should be non trivial to compute, and often not part of
      programming language standard libraries.
      2. They should be fast enough that it is a good idea to have optimized C
      implementations.
      
      Next thing I would love to see? A small strings compression algorithm.
      8a7f255c
  11. 20 Apr, 2020 1 commit
  12. 17 Apr, 2020 1 commit
  13. 08 Apr, 2020 1 commit
  14. 07 Apr, 2020 1 commit
    • antirez's avatar
      Speedup INFO by counting client memory incrementally. · f6987628
      antirez authored
      Related to #5145.
      
      Design note: clients may change type when they turn into replicas or are
      moved into the Pub/Sub category and so forth. Moreover the recomputation
      of the bytes used is problematic for obvious reasons: it changes
      continuously, so as a conservative way to avoid accumulating errors,
      each client remembers the contribution it gave to the sum, and removes
      it when it is freed or before updating it with the new memory usage.
      f6987628
  15. 02 Apr, 2020 1 commit
    • Guy Benoish's avatar
      Stale replica should allow MULTI/EXEC · 85a0d29d
      Guy Benoish authored
      Example: Client uses a pipe to send the following to a
      stale replica:
      
      MULTI
      .. do something ...
      DISCARD
      
      The replica will reply the MUTLI with -MASTERDOWN and
      execute the rest of the commands... A client using a
      pipe might not be aware that MULTI failed until it's
      too late.
      
      I can't think of a reason why MULTI/EXEC/DISCARD should
      not be executed on stale replicas...
      
      Also, enable MULTI/EXEC/DISCARD during loading
      85a0d29d
  16. 01 Apr, 2020 2 commits
    • antirez's avatar
      LCS: initial functionality implemented. · 1010c1b4
      antirez authored
      1010c1b4
    • Guy Benoish's avatar
      Fix memory corruption in moduleHandleBlockedClients · c4dc5b80
      Guy Benoish authored
      By using a "circular BRPOPLPUSH"-like scenario it was
      possible the get the same client on db->blocking_keys
      twice (See comment in moduleTryServeClientBlockedOnKey)
      
      The fix was actually already implememnted in
      moduleTryServeClientBlockedOnKey but it had a bug:
      the funxction should return 0 or 1 (not OK or ERR)
      
      Other changes:
      1. Added two commands to blockonkeys.c test module (To
         reproduce the case described above)
      2. Simplify blockonkeys.c in order to make testing easier
      3. cast raxSize() to avoid warning with format spec
      c4dc5b80
  17. 31 Mar, 2020 4 commits
  18. 27 Mar, 2020 8 commits
  19. 26 Mar, 2020 1 commit
  20. 25 Mar, 2020 2 commits
    • antirez's avatar
      PSYNC2: meaningful offset implemented. · 57fa355e
      antirez authored
      A very commonly signaled operational problem with Redis master-replicas
      sets is that, once the master becomes unavailable for some reason,
      especially because of network problems, many times it wont be able to
      perform a partial resynchronization with the new master, once it rejoins
      the partition, for the following reason:
      
      1. The master becomes isolated, however it keeps sending PINGs to the
      replicas. Such PINGs will never be received since the link connection is
      actually already severed.
      2. On the other side, one of the replicas will turn into the new master,
      setting its secondary replication ID offset to the one of the last
      command received from the old master: this offset will not include the
      PINGs sent by the master once the link was already disconnected.
      3. When the master rejoins the partion and is turned into a replica, its
      offset will be too advanced because of the PINGs, so a PSYNC will fail,
      and a full synchronization will be required.
      
      Related to issue #7002 and other discussion we had in the past around
      this problem.
      57fa355e
    • antirez's avatar
      Explain why we allow transactions in -BUSY state. · f15042db
      antirez authored
      Related to #7022.
      f15042db
  21. 23 Mar, 2020 2 commits
    • Oran Agra's avatar
      MULTI/EXEC during LUA script timeout are messed up · ec007559
      Oran Agra authored
      Redis refusing to run MULTI or EXEC during script timeout may cause partial
      transactions to run.
      
      1) if the client sends MULTI+commands+EXEC in pipeline without waiting for
      response, but these arrive to the shards partially while there's a busy script,
      and partially after it eventually finishes: we'll end up running only part of
      the transaction (since multi was ignored, and exec would fail).
      
      2) similar to the above if EXEC arrives during busy script, it'll be ignored and
      the client state remains in a transaction.
      
      the 3rd test which i added for a case where MULTI and EXEC are ok, and
      only the body arrives during busy script was already handled correctly
      since processCommand calls flagTransaction
      ec007559
    • antirez's avatar
      918086e2