1. 27 Mar, 2013 3 commits
    • antirez's avatar
      Transactions: propagate MULTI/EXEC only when needed. · 611dcb56
      antirez authored
      MULTI/EXEC is now propagated to the AOF / Slaves only once we encounter
      the first command that is not a read-only one inside the transaction.
      
      The old behavior was to always propagate an empty MULTI/EXEC block when
      the transaction was composed just of read only commands, or even
      completely empty. This created two problems:
      
      1) It's a bandwidth waste in the replication link and a space waste
         inside the AOF file.
      
      2) We used to always increment server.dirty to force the propagation of
         the EXEC command, resulting into triggering RDB saves more often
         than needed.
      
      Note: even read-only commands may also trigger writes that will be
      propagated, when we access a key that is found expired and Redis will
      synthesize a DEL operation. However there is no need for this to stay
      inside the transaction itself, but only to be ordered.
      
      So for instance something like:
      
          MULTI
          GET foo
          SET key zap
          EXEC
      
      May be propagated into:
      
          DEL foo
          MULTI
          SET key zap
          EXEC
      
      While the DEL is outside the transaction, the commands are delivered in
      the right order and it is not possible for other commands to be inserted
      between DEL and MULTI.
      611dcb56
    • antirez's avatar
      889b0174
    • antirez's avatar
      Transactions: use the propagate() API to propagate MULTI. · d1369c3d
      antirez authored
      The behavior is the same, but the code is now cleaner and uses the
      proper interface instead of dealing directly with AOF/replication
      functions.
      d1369c3d
  2. 26 Mar, 2013 1 commit
  3. 25 Mar, 2013 3 commits
    • NanXiao's avatar
      Update config.c · ef1cf15c
      NanXiao authored
      Fix bug in configGetCommand function: get correct masterauth value.
      ef1cf15c
    • antirez's avatar
      Test: obuf-limits test false positive removed. · dee8d842
      antirez authored
      Fixes #621.
      dee8d842
    • antirez's avatar
      redis-cli --stat, stolen from redis-tools. · 5576a289
      antirez authored
      Redis-tools is a connection of tools no longer mantained that was
      intented as a way to economically make sense of Redis in the pre-vmware
      sponsorship era. However there was a nice redis-stat utility, this
      commit imports one of the functionalities of this tool here in redis-cli
      as it seems to be pretty useful.
      
      Usage: redis-cli --stat
      
      The output is similar to vmstat in the format, but with Redis specific
      stuff of course.
      
      From the point of view of the monitored instance, only INFO is used in
      order to grab data.
      5576a289
  4. 13 Mar, 2013 6 commits
  5. 12 Mar, 2013 3 commits
  6. 11 Mar, 2013 12 commits
    • antirez's avatar
      Redis 2.6.11 · 65898210
      antirez authored
      65898210
    • antirez's avatar
      activeExpireCycle() smarter with many DBs and under expire pressure. · 48f4f771
      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.
      48f4f771
    • antirez's avatar
      b3281e93
    • antirez's avatar
      2677c97d
    • antirez's avatar
    • antirez's avatar
      da2dd899
    • antirez's avatar
      activeExpireCycle(): process only a small number of DBs per iteration. · 13f84841
      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.
      13f84841
    • antirez's avatar
      ef3a95fa
    • antirez's avatar
      Only resize/rehash a few databases per cron iteration. · 665b819e
      antirez authored
      This is the first step to lower the CPU usage when many databases are
      configured. The other is to also process a limited number of DBs per
      call in the active expire cycle.
      665b819e
    • antirez's avatar
      bb562a64
    • antirez's avatar
      e166abad
    • antirez's avatar
      serverCron() frequency is now a runtime parameter (was REDIS_HZ). · aec5ea5d
      antirez authored
      REDIS_HZ is the frequency our serverCron() function is called with.
      A more frequent call to this function results into less latency when the
      server is trying to handle very expansive background operations like
      mass expires of a lot of keys at the same time.
      
      Redis 2.4 used to have an HZ of 10. This was good enough with almost
      every setup, but the incremental key expiration algorithm was working a
      bit better under *extreme* pressure when HZ was set to 100 for Redis
      2.6.
      
      However for most users a latency spike of 30 milliseconds when million
      of keys are expiring at the same time is acceptable, on the other hand a
      default HZ of 100 in Redis 2.6 was causing idle instances to use some
      CPU time compared to Redis 2.4. The CPU usage was in the order of 0.3%
      for an idle instance, however this is a shame as more energy is consumed
      by the server, if not important resources.
      
      This commit introduces HZ as a runtime parameter, that can be queried by
      INFO or CONFIG GET, and can be modified with CONFIG SET. At the same
      time the default frequency is set back to 10.
      
      In this way we default to a sane value of 10, but allows users to
      easily switch to values up to 500 for near real-time applications if
      needed and if they are willing to pay this small CPU usage penalty.
      aec5ea5d
  7. 06 Mar, 2013 11 commits
  8. 04 Mar, 2013 1 commit
    • antirez's avatar
      redis-cli: use keepalive socket option. · e9318d92
      antirez authored
      This should improve things in two ways:
      
      1) Prevent timeouts caused by the execution of long commands.
      2) Improve detection of real connection errors.
      
      This is mostly effective only on Linux because of the bogus default
      keepalive settings. In Linux we have OS-specific calls to set the
      keepalive interval to reasonable values.
      e9318d92