1. 19 Nov, 2019 1 commit
  2. 14 Nov, 2019 1 commit
  3. 06 Nov, 2019 3 commits
    • antirez's avatar
      Update PR #6537: use a fresh time outside call(). · d3f4dec4
      antirez authored
      One problem with the solution proposed so far in #6537 is that key
      lookups outside a command execution via call(), still used a cached
      time. The cached time needed to be refreshed in multiple places,
      especially because of modules callbacks from timers, cluster bus, and
      thread safe contexts, that may use RM_Open().
      
      In order to avoid this problem, this commit introduces the ability to
      detect if we are inside call(): this way we can use the reference fixed
      time only when we are in the context of a command execution or Lua
      script, but for the asynchronous lookups, we can still use mstime() to
      get a fresh time reference.
      d3f4dec4
    • antirez's avatar
      Update PR #6537 patch to for generality. · 33f42665
      antirez authored
      After the thread in #6537 and thanks to the suggestions received, this
      commit updates the original patch in order to:
      
      1. Solve the problem of updating the time in multiple places by updating
      it in call().
      2. Avoid introducing a new field but use our cached time.
      
      This required some minor refactoring to the function updating the time,
      and the introduction of a new cached time in microseconds in order to
      use less gettimeofday() calls.
      33f42665
    • zhaozhao.zz's avatar
      expires: refactoring judgment about whether a key is expired · 68d71d83
      zhaozhao.zz authored
      Calling lookupKey*() many times to search a key in one command
      may get different result.
      
      That's because lookupKey*() calls expireIfNeeded(), and delete
      the key when reach the expire time. So we can get an robj before
      the expire time, but a NULL after the expire time.
      
      The worst is that may lead to Redis crash, for example
      `RPOPLPUSH foo foo` the first time we get a list form `foo` and
      hold the pointer, but when we get `foo` again it's expired and
      deleted. Now we hold a freed memory, when execute rpoplpushHandlePush()
      redis crash.
      
      To fix it, we can refactor the judgment about whether a key is expired,
      using the same basetime `server.cmd_start_mstime` instead of calling
      mstime() everytime.
      68d71d83
  4. 25 Sep, 2019 1 commit
  5. 05 Sep, 2019 1 commit
  6. 13 May, 2019 2 commits
  7. 10 May, 2019 1 commit
  8. 10 Apr, 2019 1 commit
  9. 14 Mar, 2019 4 commits
  10. 12 Dec, 2018 1 commit
  11. 11 Dec, 2018 2 commits
  12. 17 Oct, 2018 2 commits
  13. 15 Oct, 2018 1 commit
  14. 09 Oct, 2018 1 commit
  15. 03 Oct, 2018 1 commit
  16. 14 Sep, 2018 2 commits
  17. 04 Sep, 2018 2 commits
  18. 29 Aug, 2018 3 commits
  19. 02 Aug, 2018 2 commits
  20. 30 Jul, 2018 3 commits
  21. 23 Jul, 2018 2 commits
    • Itamar Haber's avatar
    • Itamar Haber's avatar
      Adds memory information about the script's cache to INFO · faf3dbfc
      Itamar Haber authored
      Implementation notes: as INFO is "already broken", I didn't want to break it further. Instead of computing the server.lua_script dict size on every call, I'm keeping a running sum of the body's length and dict overheads.
      
      This implementation is naive as it **does not** take into consideration dict rehashing, but that inaccuracy pays off in speed ;)
      
      Demo time:
      
      ```bash
      $ redis-cli info memory | grep "script"
      used_memory_scripts:96
      used_memory_scripts_human:96B
      number_of_cached_scripts:0
      $ redis-cli eval "" 0 ; redis-cli info memory | grep "script"
      (nil)
      used_memory_scripts:120
      used_memory_scripts_human:120B
      number_of_cached_scripts:1
      $ redis-cli script flush ; redis-cli info memory | grep "script"
      OK
      used_memory_scripts:96
      used_memory_scripts_human:96B
      number_of_cached_scripts:0
      $ redis-cli eval "return('Hello, Script Cache :)')" 0 ; redis-cli info memory | grep "script"
      "Hello, Script Cache :)"
      used_memory_scripts:152
      used_memory_scripts_human:152B
      number_of_cached_scripts:1
      $ redis-cli eval "return redis.sha1hex(\"return('Hello, Script Cache :)')\")" 0 ; redis-cli info memory | grep "script"
      "1be72729d43da5114929c1260a749073732dc822"
      used_memory_scripts:232
      used_memory_scripts_human:232B
      number_of_cached_scripts:2
       19:03:54 redis [lua_scripts-in-info-memory L ✚…⚑] $ redis-cli evalsha 1be72729d43da5114929c1260a749073732dc822 0
      "Hello, Script Cache :)"
      ```
      faf3dbfc
  22. 16 Jul, 2018 2 commits
    • antirez's avatar
      Hopefully improve commenting of #5126. · f9c84d6d
      antirez authored
      Reading the PR gave me the opportunity to better specify what the code
      was doing in places where I was not immediately sure about what was
      going on. Moreover I documented the structure in server.h so that people
      reading the header file will immediately understand what the structure
      is useful for.
      f9c84d6d
    • Oran Agra's avatar
      slave buffers were wasteful and incorrectly counted causing eviction · bf680b6f
      Oran Agra authored
      A) slave buffers didn't count internal fragmentation and sds unused space,
         this caused them to induce eviction although we didn't mean for it.
      
      B) slave buffers were consuming about twice the memory of what they actually needed.
      - this was mainly due to sdsMakeRoomFor growing to twice as much as needed each time
        but networking.c not storing more than 16k (partially fixed recently in 237a38737).
      - besides it wasn't able to store half of the new string into one buffer and the
        other half into the next (so the above mentioned fix helped mainly for small items).
      - lastly, the sds buffers had up to 30% internal fragmentation that was wasted,
        consumed but not used.
      
      C) inefficient performance due to starting from a small string and reallocing many times.
      
      what i changed:
      - creating dedicated buffers for reply list, counting their size with zmalloc_size
      - when creating a new reply node from, preallocate it to at least 16k.
      - when appending a new reply to the buffer, first fill all the unused space of the
        previous node before starting a new one.
      
      other changes:
      - expose mem_not_counted_for_evict info field for the benefit of the test suite
      - add a test to make sure slave buffers are counted correctly and that they don't cause eviction
      bf680b6f
  23. 09 Jul, 2018 1 commit