1. 07 Aug, 2013 11 commits
    • Jan-Erik Rediger's avatar
      Little typo · 702f3afe
      Jan-Erik Rediger authored
      702f3afe
    • antirez's avatar
      4343f0b2
    • antirez's avatar
      79635cbe
    • antirez's avatar
      d5a4c3e8
    • antirez's avatar
      d2d3ac3f
    • antirez's avatar
      Add per-db average TTL information in INFO output. · 487e6655
      antirez authored
      Example:
      
      db0:keys=221913,expires=221913,avg_ttl=655
      
      The algorithm uses a running average with only two samples (current and
      previous). Keys found to be expired are considered at TTL zero even if
      the actual TTL can be negative.
      
      The TTL is reported in milliseconds.
      487e6655
    • antirez's avatar
      activeExpireCycle(): fix about fast cycle early start. · 2e4ec793
      antirez authored
      We don't want to repeat a fast cycle too soon, the previous code was
      broken, we need to wait two times the period *since* the start of the
      previous cycle in order to avoid there is an even space between cycles:
      
      .-> start                   .-> second start
      |                           |
      +-------------+-------------+--------------+
      | first cycle |    pause    | second cycle |
      +-------------+-------------+--------------+
      
      The second and first start must be PERIOD*2 useconds apart hence the *2
      in the new code.
      2e4ec793
    • antirez's avatar
      Some activeExpireCycle() refactoring. · 1bcf296c
      antirez authored
      1bcf296c
    • antirez's avatar
      97f5e867
    • antirez's avatar
      Darft #2 for key collection algo: more improvements. · d9a4fd0f
      antirez authored
      This commit makes the fast collection cycle time configurable, at
      the same time it does not allow to run a new fast collection cycle
      for the same amount of time as the max duration of the fast
      collection cycle.
      d9a4fd0f
    • antirez's avatar
      Draft #1 of a new expired keys collection algorithm. · ab782615
      antirez authored
      The main idea here is that when we are no longer to expire keys at the
      rate the are created, we can't block more in the normal expire cycle as
      this would result in too big latency spikes.
      
      For this reason the commit introduces a "fast" expire cycle that does
      not run for more than 1 millisecond but is called in the beforeSleep()
      hook of the event loop, so much more often, and with a frequency bound
      to the frequency of executed commnads.
      
      The fast expire cycle is only called when the standard expiration
      algorithm runs out of time, that is, consumed more than
      REDIS_EXPIRELOOKUPS_TIME_PERC of CPU in a given cycle without being able
      to take the number of already expired keys that are yet not collected
      to a number smaller than 25% of the number of keys.
      
      You can test this commit with different loads, but a simple way is to
      use the following:
      
      Extreme load with pipelining:
      
      redis-benchmark -r 100000000 -n 100000000  \
              -P 32 set ele:rand:000000000000 foo ex 2
      
      Remove the -P32 in order to avoid the pipelining for a more real-world
      load.
      
      In another terminal tab you can monitor the Redis behavior with:
      
      redis-cli -i 0.1 -r -1 info keyspace
      
      and
      
      redis-cli --latency-history
      
      Note: this commit will make Redis printing a lot of debug messages, it
      is not a good idea to use it in production.
      ab782615
  2. 20 Jun, 2013 3 commits
  3. 19 Jun, 2013 2 commits
  4. 04 Jun, 2013 1 commit
  5. 14 May, 2013 1 commit
  6. 08 May, 2013 3 commits
  7. 02 May, 2013 3 commits
  8. 30 Apr, 2013 4 commits
    • antirez's avatar
      Redis 2.6.13 · d9649796
      antirez authored
      d9649796
    • antirez's avatar
      Sentinel: changes to tilt mode. · 4f38d032
      antirez authored
      Tilt mode was too aggressive (not processing INFO output), this
      resulted in a few problems:
      
      1) Redirections were not followed when in tilt mode. This opened a
         window to misinform clients about the current master when a Sentinel
         was in tilt mode and a fail over happened during the time it was not
         able to update the state.
      
      2) It was possible for a Sentinel exiting tilt mode to detect a false
         fail over start, if a slave rebooted with a wrong configuration
         about at the same time. This used to happen since in tilt mode we
         lose the information that the runid changed (reboot).
      
         Now instead the Sentinel in tilt mode will still remove the instance
         from the list of slaves if it changes state AND runid at the same
         time.
      
      Both are edge conditions but the changes should overall improve the
      reliability of Sentinel.
      4f38d032
    • antirez's avatar
      59ff2fe9
    • antirez's avatar
      Sentinel: only demote old master into slave under certain conditions. · fb0d08e3
      antirez authored
      We used to always turn a master into a slave if the DEMOTE flag was set,
      as this was a resurrecting master instance.
      
      However the following race condition is possible for a Sentinel that
      got partitioned or internal issues (tilt mode), and was not able to
      refresh the state in the meantime:
      
      1) Sentinel X is running, master is instance "A".
      3) "A" fails, sentinels will promote slave "B" as master.
      2) Sentinel X goes down because of a network partition.
      4) "A" returns available, Sentinels will demote it as a slave.
      5) "B" fails, other Sentinels will promote slave "A" as master.
      6) At this point Sentinel X comes back.
      
      When "X" comes back he thinks that:
      
      "B" is the master.
      "A" is the slave to demote.
      
      We want to avoid that Sentinel "X" will demote "A" into a slave.
      We also want that Sentinel "X" will detect that the conditions changed
      and will reconfigure itself to monitor the right master.
      
      There are two main ways for the Sentinel to reconfigure itself after
      this event:
      
      1) If "B" is reachable and already configured as a slave by other
      sentinels, "X" will perform a redirection to "A".
      2) If there are not the conditions to demote "A", the fact that "A"
      reports to be a master will trigger a failover detection in "X", that
      will end into a reconfiguraiton to monitor "A".
      
      However if the Sentinel was not reachable, its state may not be updated,
      so in case it titled, or was partiitoned from the master instance of the
      slave to demote, the new implementation waits some time (enough to
      guarantee we can detect the new INFO, and new DOWN conditions).
      
      If after some time still there are not the right condiitons to demote
      the instance, the DEMOTE flag is cleared.
      fb0d08e3
  9. 29 Apr, 2013 1 commit
  10. 24 Apr, 2013 4 commits
    • antirez's avatar
      Sentinel: always redirect on master->slave transition. · 34a57a5b
      antirez authored
      Sentinel redirected to the master if the instance changed runid or it
      was the first time we got INFO, and a role change was detected from
      master to slave.
      
      While this is a good idea in case of slave->master, since otherwise we
      could detect a failover without good reasons just after a reboot with a
      slave with a wrong configuration, in the case of master->slave
      transition is much better to always perform the redirection for the
      following reasons:
      
      1) A Sentinel may go down for some time. When it is back online there is
      no other way to understand there was a failover.
      2) Pointing clients to a slave seems to be always the wrong thing to do.
      3) There is no good rationale about handling things differently once an
      instance is rebooted (runid change) in that case.
      34a57a5b
    • antirez's avatar
      967ae8ca
    • antirez's avatar
      AOF: sync data on disk every 32MB when rewriting. · c735116c
      antirez authored
      This prevents the kernel from putting too much stuff in the output
      buffers, doing too heavy I/O all at once. So the goal of this commit is
      to split the disk pressure due to the AOF rewrite process into smaller
      spikes.
      
      Please see issue #1019 for more information.
      c735116c
    • antirez's avatar
  11. 23 Apr, 2013 1 commit
    • antirez's avatar
      Test: fix RDB test checking file permissions. · cf7b2c32
      antirez authored
      When the test is executed using the root account, setting the permission
      to 222 does not work as expected, as root can read files with 222
      permission.
      
      Now we skip the test if root is detected.
      
      This fixes issue #1034 and the duplicated #1040 issue.
      
      Thanks to Jan-Erik Rediger (@badboy on Github) for finding a way to reproduce the issue.
      cf7b2c32
  12. 22 Apr, 2013 2 commits
  13. 19 Apr, 2013 1 commit
  14. 18 Apr, 2013 1 commit
    • antirez's avatar
      Redis/Jemalloc Gitignore were too aggressive. · 5bf9b53a
      antirez authored
      Redis gitignore was too aggressive since simply broken.
      
      Jemalloc gitignore was too agressive because it is conceived to just
      keep the files that allow to generate all the rest in development
      environments (so for instance the "configure" file is excluded).
      5bf9b53a
  15. 11 Apr, 2013 2 commits
    • antirez's avatar
      redis-cli: raise error on bad command line switch. · 40861516
      antirez authored
      Previously redis-cli never tried to raise an error when an unrecognized
      switch was encountered, as everything after the initial options is to be
      transmitted to the server.
      
      However this is too liberal, as there are no commands starting with "-".
      So the new behavior is to produce an error if there is an unrecognized
      switch starting with "-". This should not break past redis-cli usages
      but should prevent broken options to be silently discarded.
      
      As far the first token not starting with "-" is encountered, all the
      rest is considered to be part of the command, so you cna still use
      strings starting with "-" as values, like in:
      
          redis-cli --port 6380 set foo --my-value
      40861516
    • antirez's avatar
      redis-cli: --latency-history mode implemented. · 92a7b010
      antirez authored
      92a7b010