- 11 Sep, 2018 2 commits
- 05 Sep, 2018 1 commit
-
-
antirez authored
-
- 04 Sep, 2018 1 commit
-
-
maya-rv authored
-
- 31 Aug, 2018 1 commit
-
-
antirez authored
See #5297.
-
- 26 Aug, 2018 1 commit
-
-
Chris Lamb authored
-
- 21 Aug, 2018 1 commit
-
-
Oran Agra authored
Few tests had borderline thresholds that were adjusted. The slave buffers test had two issues, preventing the slave buffer from growing: 1) the slave didn't necessarily go to sleep on time, or woke up too early, now using SIGSTOP to make sure it goes to sleep exactly when we want. 2) the master disconnected the slave on timeout
-
- 13 Aug, 2018 1 commit
-
-
zhaozhao.zz authored
-
- 02 Aug, 2018 3 commits
- 31 Jul, 2018 1 commit
-
-
antirez authored
-
- 30 Jul, 2018 1 commit
-
-
Oran Agra authored
* allowing --single to be repeated * adding --only so that only a specific test inside a unit can be run * adding --skiptill useful to resume a test that crashed passed the problematic unit. useful together with --clients 1 * adding --skipfile to use a file containing list of tests names to skip * printing the names of the tests that are skiped by skipfile or denytags * adding --config to add config file options from command line
-
- 24 Jul, 2018 1 commit
-
-
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.
-
- 18 Jul, 2018 1 commit
-
-
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.
-
- 16 Jul, 2018 1 commit
-
-
Oran Agra authored
A) slave buffers didn't count internal fragmentation and sds unused space, this caused them to induce eviction although we didn't mean for it. B) slave buffers were consuming about twice the memory of what they actually needed. - this was mainly due to sdsMakeRoomFor growing to twice as much as needed each time but networking.c not storing more than 16k (partially fixed recently in 237a38737). - besides it wasn't able to store half of the new string into one buffer and the other half into the next (so the above mentioned fix helped mainly for small items). - lastly, the sds buffers had up to 30% internal fragmentation that was wasted, consumed but not used. C) inefficient performance due to starting from a small string and reallocing many times. what i changed: - creating dedicated buffers for reply list, counting their size with zmalloc_size - when creating a new reply node from, preallocate it to at least 16k. - when appending a new reply to the buffer, first fill all the unused space of the previous node before starting a new one. other changes: - expose mem_not_counted_for_evict info field for the benefit of the test suite - add a test to make sure slave buffers are counted correctly and that they don't cause eviction
-
- 13 Jul, 2018 6 commits
- 12 Jul, 2018 1 commit
-
-
antirez authored
-
- 03 Jul, 2018 1 commit
-
-
Jack Drogon authored
-
- 02 Jul, 2018 1 commit
-
-
WuYunlong authored
Issue #5063 added --wait-server option, but can not work.
-
- 01 Jul, 2018 1 commit
-
-
chendianqiang authored
-
- 30 Jun, 2018 1 commit
-
-
WuYunlong authored
-
- 27 Jun, 2018 2 commits
- 26 Jun, 2018 2 commits
- 21 Jun, 2018 1 commit
-
-
shenlongxing authored
-
- 20 Jun, 2018 1 commit
-
-
Guy Benoish authored
RESTORE now supports: 1. Setting LRU/LFU 2. Absolute-time TTL Other related changes: 1. RDB loading will not override LRU bits when RDB file does not contain the LRU opcode. 2. RDB loading will not set LRU/LFU bits if the server's maxmemory-policy does not match.
-
- 19 Jun, 2018 1 commit
-
-
antirez authored
-
- 14 Jun, 2018 1 commit
-
-
antirez authored
-
- 12 Jun, 2018 1 commit
-
-
antirez authored
-
- 11 Jun, 2018 2 commits
-
-
antirez authored
Removing the fix about 50% of the times the test will not be able to pass cleanly. It's very hard to write a test that will always fail, or actually, it is possible but then it's likely that it will consistently pass if we change some random bit, so better to use randomization here.
-
antirez authored
-
- 05 Jun, 2018 1 commit
-
-
antirez authored
-
- 25 May, 2018 1 commit
-
-
antirez authored
-