1. 12 Mar, 2018 2 commits
    • Oran Agra's avatar
      Adding real allocator fragmentation to INFO and MEMORY command + active defrag test · 806736cd
      Oran Agra authored
      other fixes / improvements:
      - LUA script memory isn't taken from zmalloc (taken from libc malloc)
        so it can cause high fragmentation ratio to be displayed (which is false)
      - there was a problem with "fragmentation" info being calculated from
        RSS and used_memory sampled at different times (now sampling them together)
      
      other details:
      - adding a few more allocator info fields to INFO and MEMORY commands
      - improve defrag test to measure defrag latency of big keys
      - increasing the accuracy of the defrag test (by looking at real grag info)
        this way we can use an even lower threshold and still avoid false positives
      - keep the old (total) "fragmentation" field unchanged, but add new ones for spcific things
      - add these the MEMORY DOCTOR command
      - deduct LUA memory from the rss in case of non jemalloc allocator (one for which we don't "allocator active/used")
      - reduce sampling rate of the rss and allocator info
      806736cd
    • Oran Agra's avatar
      active defrag v2 · be1b4aa9
      Oran Agra authored
      - big keys are not defragged in one go from within the dict scan
        instead they are scanned in parts after the main dict hash bucket is done.
      - add latency monitor sample for defrag
      - change default active-defrag-cycle-min to induce lower latency
      - make active defrag start a new scan right away if needed, so it's easier
        (for the test suite) to detect when it's done
      - make active defrag quick the current cycle after each db / big key
      - defrag  some non key long term global allocations
      - some refactoring for smaller functions and more reusable code
      - during dict rehashing, one scan iteration of the dict, can end up scanning
        one bucket in the smaller dict and many many buckets in the larger dict.
        so waiting for 16 scan iterations before checking the time, may be much too long.
      be1b4aa9
  2. 15 Feb, 2018 2 commits
  3. 14 Feb, 2018 10 commits
  4. 13 Feb, 2018 5 commits
  5. 02 Feb, 2018 1 commit
  6. 23 Jan, 2018 1 commit
  7. 18 Jan, 2018 3 commits
    • antirez's avatar
      727dd436
    • Guy Benoish's avatar
      Replication buffer fills up on high rate traffic. · fd8efb7c
      Guy Benoish authored
      When feeding the master with a high rate traffic the the slave's feed is much slower.
      This causes the replication buffer to grow (indefinitely) which leads to slave disconnection.
      The problem is that writeToClient() decides to stop writing after NET_MAX_WRITES_PER_EVENT
      writes (In order to be fair to clients).
      We should ignore this when the client is a slave.
      It's better if clients wait longer, the alternative is that the slave has no chance to stay in
      sync in this situation.
      fd8efb7c
    • antirez's avatar
      Cluster: improve anti-affinity algo in redis-trib.rb. · 1673a3f3
      antirez authored
      See #3462 and related PRs.
      
      We use a simple algorithm to calculate the level of affinity violation,
      and then an optimizer that performs random swaps until things improve.
      1673a3f3
  8. 17 Jan, 2018 2 commits
  9. 16 Jan, 2018 3 commits
  10. 15 Jan, 2018 2 commits
  11. 14 Jan, 2018 1 commit
  12. 12 Jan, 2018 1 commit
    • antirez's avatar
      Fix getKeysUsingCommandTable() in the case of nagative arity. · 2f8476df
      antirez authored
      This fixes a crash with Redis Cluster when OBJECT is mis-used, because
      getKeysUsingCommandTable() will call serverPanic() detecting we are
      accessing an invalid argument in the case "OBJECT foo" is called.
      
      This bug was introduced when OBJECT HELP was introduced, because the key
      argument is set fixed at index 2 in the command table, however now
      OBJECT may be called with an insufficient number of arguments to extract
      the key.
      
      The "Right Thing" would be to have a specific function to extract keys
      from the OBJECT command, however this is kinda of an overkill, so I
      preferred to make getKeysUsingCommandTable() more robust and just return
      no keys when it's not possible to honor the command table, because new
      commands are often added and also there are a number with an HELP
      subcommand violating the normal form, and crashing for this trivial
      reason or having many command-specific key extraction functions is not
      great.
      2f8476df
  13. 11 Jan, 2018 2 commits
  14. 09 Jan, 2018 2 commits
  15. 07 Jan, 2018 1 commit
  16. 05 Jan, 2018 1 commit
  17. 03 Jan, 2018 1 commit