1. 18 Jul, 2018 1 commit
    • Oran Agra's avatar
      make active defrag test more stable · f89c93c8
      Oran Agra authored
      on slower machines, the active defrag test tended to fail.
      although the fragmentation ratio was below the treshold, the defragger was
      still in the middle of a scan cycle.
      
      this commit changes:
      - the defragger uses the current fragmentation state, rather than the cache one
        that is updated by server cron every 100ms. this actually fixes a bug of
        starting one excess scan cycle
      - the test lets the defragger use more CPU cycles, in hope that the defrag
        will be faster, but also give it more time before we give up.
      f89c93c8
  2. 27 Jun, 2018 1 commit
  3. 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
  4. 05 Dec, 2017 1 commit
  5. 12 Jan, 2017 1 commit
  6. 11 Jan, 2017 2 commits
  7. 10 Jan, 2017 2 commits
  8. 02 Jan, 2017 1 commit
  9. 30 Dec, 2016 1 commit