- 04 Feb, 2019 1 commit
-
-
antirez authored
-
- 21 Jan, 2019 1 commit
-
-
zhaozhao.zz authored
-
- 18 Jan, 2019 2 commits
- 17 Jan, 2019 1 commit
-
-
antirez authored
-
- 09 Jan, 2019 1 commit
-
-
antirez authored
-
- 12 Dec, 2018 1 commit
-
-
antirez authored
Related to issue #5686 and PR #5689.
-
- 07 Nov, 2018 1 commit
-
-
antirez authored
Thanks to @NicolasLM, see issue #5537.
-
- 21 Oct, 2018 1 commit
-
-
hujie authored
-
- 13 Sep, 2018 1 commit
-
-
antirez authored
-
- 11 Sep, 2018 2 commits
- 05 Sep, 2018 1 commit
-
-
antirez authored
See issue #5250 and issue #5292 for more info.
-
- 27 Aug, 2018 3 commits
- 30 Jul, 2018 1 commit
-
-
antirez authored
-
- 23 Jul, 2018 1 commit
-
-
antirez authored
This way we can remember what the user configured HZ is, but change the actual HZ dynamically if needed in the dynamic HZ feature implementation.
-
- 13 Jul, 2018 1 commit
-
-
WuYunlong authored
-
- 02 Jul, 2018 1 commit
-
-
antirez authored
-
- 27 Jun, 2018 1 commit
-
-
Oran Agra authored
-
- 13 Jun, 2018 1 commit
-
-
shenlongxing authored
-
- 12 Jun, 2018 1 commit
-
-
Shen Longxing authored
The active-defrag-threshold-lower/active-defrag-threshold-upper min/max value in redis.conf should be consistent with 'config set' command.
-
- 09 Jun, 2018 2 commits
-
-
Itamar Haber authored
-
shenlongxing authored
-
- 07 Jun, 2018 2 commits
-
-
Itamar Haber authored
-
antirez authored
-
- 24 May, 2018 1 commit
-
-
antirez authored
They failed when active defrag could not be activated because the Jemalloc version does not include the additional APIs.
-
- 15 Mar, 2018 1 commit
-
-
zhaozhao.zz authored
-
- 14 Mar, 2018 1 commit
-
-
antirez authored
This commit, in some parts derived from PR #3041 which is no longer possible to merge (because the user deleted the original branch), implements the ability of slaves to have a special configuration preventing that they try to start a failover when the master is failing. There are multiple reasons for wanting this, and the feautre was requested in issue #3021 time ago. The differences between this patch and the original PR are the following: 1. The flag is saved/loaded on the nodes configuration. 2. The 'myself' node is now flag-aware, the flag is updated as needed when the configuration is changed via CONFIG SET. 3. The flag name uses NOFAILOVER instead of NO_FAILOVER to be consistent with existing NOADDR. 4. The redis.conf documentation was rewritten. Thanks to @deep011 for the original patch.
-
- 12 Mar, 2018 1 commit
-
-
Oran Agra authored
- big keys are not defragged in one go from within the dict scan instead they are scanned in parts after the main dict hash bucket is done. - add latency monitor sample for defrag - change default active-defrag-cycle-min to induce lower latency - make active defrag start a new scan right away if needed, so it's easier (for the test suite) to detect when it's done - make active defrag quick the current cycle after each db / big key - defrag some non key long term global allocations - some refactoring for smaller functions and more reusable code - during dict rehashing, one scan iteration of the dict, can end up scanning one bucket in the smaller dict and many many buckets in the larger dict. so waiting for 16 scan iterations before checking the time, may be much too long.
-
- 26 Jan, 2018 1 commit
-
-
zhaozhao.zz authored
-
- 11 Jan, 2018 2 commits
- 29 Dec, 2017 1 commit
-
-
Oran Agra authored
-
- 06 Dec, 2017 1 commit
-
-
antirez authored
The main change introduced by this commit is pretending that help arrays are more text than code, thus indenting them at level 0. This improves readability, and is an old practice when defining arrays of C strings describing text. Additionally a few useless return statements are removed, and the HELP subcommand capitalized when printed to the user.
-
- 03 Dec, 2017 1 commit
-
-
Itamar Haber authored
-
- 27 Nov, 2017 1 commit
-
-
zhaozhao.zz authored
-
- 15 Jul, 2017 1 commit
-
-
WuYunlong authored
-
- 20 Feb, 2017 1 commit
-
-
antirez authored
This change attempts to switch to an hash function which mitigates the effects of the HashDoS attack (denial of service attack trying to force data structures to worst case behavior) while at the same time providing Redis with an hash function that does not expect the input data to be word aligned, a condition no longer true now that sds.c strings have a varialbe length header. Note that it is possible sometimes that even using an hash function for which collisions cannot be generated without knowing the seed, special implementation details or the exposure of the seed in an indirect way (for example the ability to add elements to a Set and check the return in which Redis returns them with SMEMBERS) may make the attacker's life simpler in the process of trying to guess the correct seed, however the next step would be to switch to a log(N) data structure when too many items in a single bucket are detected: this seems like an overkill in the case of Redis. SPEED REGRESION TESTS: In order to verify that switching from MurmurHash to SipHash had no impact on speed, a set of benchmarks involving fast insertion of 5 million of keys were performed. The result shows Redis with SipHash in high pipelining conditions to be about 4% slower compared to using the previous hash function. However this could partially be related to the fact that the current implementation does not attempt to hash whole words at a time but reads single bytes, in order to have an output which is endian-netural and at the same time working on systems where unaligned memory accesses are a problem. Further X86 specific optimizations should be tested, the function may easily get at the same level of MurMurHash2 if a few optimizations are performed.
-