- 08 Aug, 2013 2 commits
-
-
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.
-
antirez authored
This change was profiler-driven, but the actual effect is hard to measure in real-world redis benchmark runs.
-
- 07 Aug, 2013 11 commits
-
-
Jan-Erik Rediger authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
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.
-
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.
-
antirez authored
-
antirez authored
-
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.
-
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.
-
- 20 Jun, 2013 3 commits
- 19 Jun, 2013 2 commits
- 04 Jun, 2013 1 commit
-
-
antirez authored
-
- 14 May, 2013 1 commit
-
-
antirez authored
-
- 08 May, 2013 3 commits
-
-
antirez authored
The test actually worked, but vars for master and slave were inverted and sometimes used incorrectly.
-
Jiahao Huang authored
bitcount commant may return negtive integer with string length more than 256 MB
-
antirez authored
-
- 02 May, 2013 3 commits
-
-
antirez authored
This is just to make the code exactly like the above instance used for requirepass. No actual change nor the original code violated the Redis coding style.
-
Michel Martens authored
-
charsyam authored
There was a race condition in the AOF rewrite code that, with bad enough timing, could cause a volatile key just about to expire to be turned into a non-volatile key. The bug was never reported to cause actualy issues, but was found analytically by an user in the Redis mailing list: https://groups.google.com/forum/?fromgroups=#!topic/redis-db/Kvh2FAGK4Uk This commit fixes issue #1079.
-
- 30 Apr, 2013 4 commits
-
-
antirez authored
-
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.
-
antirez authored
-
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.
-
- 29 Apr, 2013 1 commit
-
-
antirez authored
-
- 24 Apr, 2013 4 commits
-
-
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.
-
antirez authored
-
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.
-
antirez authored
-
- 23 Apr, 2013 1 commit
-
-
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.
-
- 22 Apr, 2013 2 commits
- 19 Apr, 2013 1 commit
-
-
antirez authored
-
- 18 Apr, 2013 1 commit
-
-
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).
-