- 10 Jan, 2018 1 commit
-
-
huijing.whj authored
-
- 28 Nov, 2017 1 commit
-
-
antirez authored
Splitting the popularity in half actually just needs decrementing the counter because the counter is logarithmic.
-
- 27 Nov, 2017 2 commits
-
-
zhaozhao.zz authored
Firstly, use access time to replace the decreas time of LFU. For function LFUDecrAndReturn, it should only try to get decremented counter, not update LFU fields, we will update it in an explicit way. And we will times halve the counter according to the times of elapsed time than server.lfu_decay_time. Everytime a key is accessed, we should update the LFU including update access time, and increment the counter after call function LFUDecrAndReturn. If a key is overwritten, the LFU should be also updated. Then we can use `OBJECT freq` command to get a key's frequence, and LFUDecrAndReturn should be called in `OBJECT freq` command in case of the key has not been accessed for a long time, because we update the access time only when the key is read or overwritten.
-
zhaozhao.zz authored
-
- 23 Jun, 2017 1 commit
-
-
antirez authored
It looks safer to return C_OK from freeMemoryIfNeeded() when clients are paused because returning C_ERR may prevent success of writes. It is possible that there is no difference in practice since clients cannot execute writes while clients are paused, but it looks more correct this way, at least conceptually. Related to PR #4028.
-
- 01 Jun, 2017 1 commit
-
-
Zachary Marquez authored
Proposed fix to https://github.com/antirez/redis/issues/4027
-
- 09 May, 2017 1 commit
-
-
antirez authored
More work to do with server.unixtime and similar. Need to write Helgrind suppression file in order to suppress the valse positives.
-
- 21 Feb, 2017 1 commit
-
-
antirez authored
1. Refactor memory overhead computation into a function. 2. Every 10 keys evicted, check if memory usage already reached the target value directly, since we otherwise don't count all the memory reclaimed by the background thread right now.
-
- 20 Jul, 2016 2 commits
- 18 Jul, 2016 3 commits
-
-
antirez authored
Verified to have better real world performances with power-law access patterns because of the data accumulated across calls.
-
antirez authored
-
antirez authored
It is possible to get better results by using the pool like in the LRU case. Also from tests during the morning I believe the current implementation has issues in the frequency decay function that should decrease the counter at periodic intervals.
-
- 15 Jul, 2016 1 commit
-
-
antirez authored
Implementation of LFU maxmemory policy for anything related to Redis objects. Still no actual eviction implemented.
-
- 13 Jul, 2016 1 commit
-
-
antirez authored
The LRU eviction code used to make local choices: for each DB visited it selected the best key to evict. This was repeated for each DB. However this means that there could be DBs with very frequently accessed keys that are targeted by the LRU algorithm while there were other DBs with many better candidates to expire. This commit attempts to fix this problem for the LRU policy. However the TTL policy is still not fixed by this commit. The TTL policy will be fixed in a successive commit. This is an initial (partial because of TTL policy) fix for issue #2647.
-
- 12 Jul, 2016 3 commits
-
-
antirez authored
To destroy and recreate the pool[].key element is slow, so we allocate in pool[].cached SDS strings that can account up to 255 chars keys and try to reuse them. This provides a solid 20% performance improvement in real world workload alike benchmarks.
-
antirez authored
Local scope is always better when possible.
-
antirez authored
-
- 11 Jul, 2016 1 commit
-
-
antirez authored
We start from the end of the pool to the initial item, zero-ing every entry we use or every ghost entry, there is nothing to memmove since to the right everything should be already set to NULL.
-
- 06 Jul, 2016 1 commit
-
-
antirez authored
-