1. 17 Mar, 2013 3 commits
  2. 16 Mar, 2013 3 commits
  3. 15 Mar, 2013 11 commits
  4. 14 Mar, 2013 5 commits
  5. 13 Mar, 2013 8 commits
  6. 12 Mar, 2013 4 commits
  7. 11 Mar, 2013 3 commits
    • antirez's avatar
      activeExpireCycle() smarter with many DBs and under expire pressure. · 2d851333
      antirez authored
      activeExpireCycle() tries to test just a few DBs per iteration so that
      it scales if there are many configured DBs in the Redis instance.
      However this commit makes it a bit smarter when one a few of those DBs
      are under expiration pressure and there are many many keys to expire.
      
      What we do is to remember if in the last iteration had to return because
      we ran out of time. In that case the next iteration we'll test all the
      configured DBs so that we are sure we'll test again the DB under
      pressure.
      
      Before of this commit after some mass-expire in a given DB the function
      tested just a few of the next DBs, possibly empty, a few per iteration,
      so it took a long time for the function to reach again the DB under
      pressure. This resulted in a lot of memory being used by already expired
      keys and never accessed by clients.
      2d851333
    • antirez's avatar
      08b107e4
    • antirez's avatar
      4b1ccdfd
  8. 09 Mar, 2013 2 commits
  9. 08 Mar, 2013 1 commit
    • antirez's avatar
      activeExpireCycle(): process only a small number of DBs per iteration. · db29d71a
      antirez authored
      This small number of DBs is set to 16 so actually in the default
      configuraiton Redis should behave exactly like in the past.
      However the difference is that when the user configures a very large
      number of DBs we don't do an O(N) operation, consuming a non trivial
      amount of CPU per serverCron() iteration.
      db29d71a