1. 27 Aug, 2013 4 commits
  2. 21 Aug, 2013 1 commit
  3. 20 Aug, 2013 2 commits
  4. 19 Aug, 2013 8 commits
    • antirez's avatar
      Revert "Fixed type in dict.c comment: 265 -> 256." · 3bacf4c7
      antirez authored
      This reverts commit 19de8e46.
      3bacf4c7
    • antirez's avatar
      Fixed type in dict.c comment: 265 -> 256. · 19de8e46
      antirez authored
      19de8e46
    • antirez's avatar
      assert.h replaced with redisassert.h when appropriate. · e16dd1d8
      antirez authored
      Also a warning was suppressed by including unistd.h in redisassert.h
      (needed for _exit()).
      e16dd1d8
    • antirez's avatar
      Added redisassert.h as drop in replacement for assert.h. · 85070a30
      antirez authored
      By using redisassert.h version of assert() you get stack traces in the
      log instead of a process disappearing on assertions.
      85070a30
    • antirez's avatar
      dictFingerprint() fingerprinting made more robust. · 3a40b02d
      antirez authored
      The previous hashing used the trivial algorithm of xoring the integers
      together. This is not optimal as it is very likely that different
      hash table setups will hash the same, for instance an hash table at the
      start of the rehashing process, and at the end, will have the same
      fingerprint.
      
      Now we hash N integers in a smarter way, by summing every integer to the
      previous hash, and taking the integer hashing again (see the code for
      further details). This way it is a lot less likely that we get a
      collision. Moreover this way of hashing explicitly protects from the
      same set of integers in a different order to hash to the same number.
      
      This commit is related to issue #1240.
      3a40b02d
    • antirez's avatar
      Fix comments for correctness in zunionInterGenericCommand(). · d9bf918d
      antirez authored
      Related to issue #1240.
      d9bf918d
    • antirez's avatar
      Properly init/release iterators in zunionInterGenericCommand(). · bf3932ed
      antirez authored
      This commit does mainly two things:
      
      1) It fixes zunionInterGenericCommand() by removing mass-initialization
      of all the iterators used, so that we don't violate the unsafe iterator
      API of dictionaries. This fixes issue #1240.
      
      2) Since the zui* APIs required the allocator to be initialized in the
      zsetopsrc structure in order to use non-iterator related APIs, this
      commit fixes this strict requirement by accessing objects directly via
      the op->subject->ptr pointer we have to the object.
      bf3932ed
    • antirez's avatar
      dict.c iterator API misuse protection. · 4a005a2a
      antirez authored
      dict.c allows the user to create unsafe iterators, that are iterators
      that will not touch the dictionary data structure in any way, preventing
      copy on write, but at the same time are limited in their usage.
      
      The limitation is that when itearting with an unsafe iterator, no call
      to other dictionary functions must be done inside the iteration loop,
      otherwise the dictionary may be incrementally rehashed resulting into
      missing elements in the set of the elements returned by the iterator.
      
      However after introducing this kind of iterators a number of bugs were
      found due to misuses of the API, and we are still finding
      bugs about this issue. The bugs are not trivial to track because the
      effect is just missing elements during the iteartion.
      
      This commit introduces auto-detection of the API misuse. The idea is
      that an unsafe iterator has a contract: from initialization to the
      release of the iterator the dictionary should not change.
      
      So we take a fingerprint of the dictionary state, xoring a few important
      dict properties when the unsafe iteartor is initialized. We later check
      when the iterator is released if the fingerprint is still the same. If it
      is not, we found a misuse of the iterator, as not allowed API calls
      changed the internal state of the dictionary.
      
      This code was checked against a real bug, issue #1240.
      
      This is what Redis prints (aborting) when a misuse is detected:
      
      Assertion failed: (iter->fingerprint == dictFingerprint(iter->d)),
      function dictReleaseIterator, file dict.c, line 587.
      4a005a2a
  5. 12 Aug, 2013 1 commit
  6. 08 Aug, 2013 2 commits
    • antirez's avatar
      redis-benchmark: changes to random arguments substitution. · 1c4e3011
      antirez authored
      Before this commit redis-benchmark supported random argumetns in the
      form of :rand:000000000000. In every string of that form, the zeros were
      replaced with a random number of 12 digits at every command invocation.
      
      However this was far from perfect as did not allowed to generate simply
      random numbers as arguments, there was always the :rand: prefix.
      
      Now instead every argument in the form __rand_int__ is replaced with a
      12 digits number. Note that "__rand_int__" is 12 characters itself.
      
      In order to implement the new semantic, it was needed to change a few
      thigns in the internals of redis-benchmark, as new clients are created
      cloning old clients, so without a stable prefix such as ":rand:" the old
      way of cloning the client was no longer able to understand, from the old
      command line, what was the position of the random strings to substitute.
      
      Now instead a client structure is passed as a reference for cloning, so
      that we can directly clone the offsets inside the command line.
      1c4e3011
    • antirez's avatar
      redis-benchmark: replace snprintf()+memcpy with faster code. · f4f93131
      antirez authored
      This change was profiler-driven, but the actual effect is hard to
      measure in real-world redis benchmark runs.
      f4f93131
  7. 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
  8. 20 Jun, 2013 3 commits
  9. 19 Jun, 2013 2 commits
  10. 04 Jun, 2013 1 commit
  11. 14 May, 2013 1 commit
  12. 08 May, 2013 3 commits
  13. 02 May, 2013 1 commit