- 30 Jul, 2018 6 commits
-
-
antirez authored
-
zhaozhao.zz authored
-
zhaozhao.zz authored
-
antirez authored
Related to #5154.
-
antirez authored
-
WuYunlong authored
-
- 24 Jul, 2018 9 commits
-
-
antirez authored
After #5161 the code could be made a bit more obvious for newcomers.
-
zhaozhao.zz authored
-
Oran Agra authored
it looks like on slow machines we're getting: [err]: slave buffer are counted correctly in tests/unit/maxmemory.tcl Expected condition '$slave_buf > 2*1024*1024' to be true (16914 > 2*1024*1024) this is a result of the slave waking up too early and eating the slave buffer before the traffic and the test ends.
-
antirez authored
-
dsomeshwar authored
-
antirez authored
See PR #5157.
-
Oran Agra authored
-
antirez authored
Related to #5157. The PR author correctly indentified that the check was duplicated, but removing the second one introduces a bug that was fixed in the past (hence the duplication). Instead we can remove the first instance of the check without issues.
-
antirez authored
-
- 23 Jul, 2018 5 commits
-
-
antirez authored
Related to #4883.
-
Itamar Haber authored
-
Itamar Haber authored
Implementation notes: as INFO is "already broken", I didn't want to break it further. Instead of computing the server.lua_script dict size on every call, I'm keeping a running sum of the body's length and dict overheads. This implementation is naive as it **does not** take into consideration dict rehashing, but that inaccuracy pays off in speed ;) Demo time: ```bash $ redis-cli info memory | grep "script" used_memory_scripts:96 used_memory_scripts_human:96B number_of_cached_scripts:0 $ redis-cli eval "" 0 ; redis-cli info memory | grep "script" (nil) used_memory_scripts:120 used_memory_scripts_human:120B number_of_cached_scripts:1 $ redis-cli script flush ; redis-cli info memory | grep "script" OK used_memory_scripts:96 used_memory_scripts_human:96B number_of_cached_scripts:0 $ redis-cli eval "return('Hello, Script Cache :)')" 0 ; redis-cli info memory | grep "script" "Hello, Script Cache :)" used_memory_scripts:152 used_memory_scripts_human:152B number_of_cached_scripts:1 $ redis-cli eval "return redis.sha1hex(\"return('Hello, Script Cache :)')\")" 0 ; redis-cli info memory | grep "script" "1be72729d43da5114929c1260a749073732dc822" used_memory_scripts:232 used_memory_scripts_human:232B number_of_cached_scripts:2
✔ 19:03:54 redis [lua_scripts-in-info-memory L ✚…⚑] $ redis-cli evalsha 1be72729d43da5114929c1260a749073732dc822 0 "Hello, Script Cache :)" ``` -
antirez authored
For some reason I made a merge fiasco between 5.0 and unstable. This fixes the error introduced by merging unstable.
-
antirez authored
-
- 20 Jul, 2018 2 commits
- 19 Jul, 2018 9 commits
-
-
antirez authored
They are actually delayed a few seconds, so let's call them "recent".
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
Related to #4727.
-
Salvatore Sanfilippo authored
move getClientsMaxBuffers func into info clients command
-
- 18 Jul, 2018 5 commits
-
-
antirez authored
-
antirez authored
See #5135 for more context.
-
antirez authored
See #5135 for some context.
-
Salvatore Sanfilippo authored
make active defrag test more stable
-
Oran Agra authored
on slower machines, the active defrag test tended to fail. although the fragmentation ratio was below the treshold, the defragger was still in the middle of a scan cycle. this commit changes: - the defragger uses the current fragmentation state, rather than the cache one that is updated by server cron every 100ms. this actually fixes a bug of starting one excess scan cycle - the test lets the defragger use more CPU cycles, in hope that the defrag will be faster, but also give it more time before we give up.
-
- 17 Jul, 2018 4 commits
-
-
Salvatore Sanfilippo authored
Accept write commands if persisting is disabled
-
Salvatore Sanfilippo authored
Update the comment
-
antirez authored
-
Salvatore Sanfilippo authored
Fix xreadgroup with '$' ID.
-