- 22 2月, 2012 6 次提交
-
-
由 antirez 提交于
-
由 antirez 提交于
zzlIsInRange() now is capable of handling empty sorted sets that may end inside the data set when loading very old RDB files produced by early-stage versions of Redis.
-
由 Salvatore Sanfilippo 提交于
Force SIGSEGV without HAVE_BACKTRACE (2.4)
-
由 Pieter Noordhuis 提交于
-
由 Pieter Noordhuis 提交于
-
由 antirez 提交于
-
- 21 2月, 2012 6 次提交
- 16 2月, 2012 2 次提交
- 15 2月, 2012 11 次提交
-
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
Fixes to c->reply_bytes computation, and debug messages to closely study the behavior of memory pressure + slaves + maxmemory + blocked slaves.
-
由 antirez 提交于
Precision of getClientOutputBufferMemoryUsage() greatily improved, see issue #327 for more information.
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
1) sendReplyToClient() now no longer stops transferring data to a single client in the case we are out of memory (maxmemory-wise). 2) in processCommand() the idea of we being out of memory is no longer the naive zmalloc_used_memory() > server.maxmemory. To say if we can accept or not write queries is up to the return value of freeMemoryIfNeeded(), that has full control about that. 3) freeMemoryIfNeeded() now does its math without considering output buffers size. But at the same time it can't let the output buffers to put us too much outside the max memory limit, so at the same time it makes sure there is enough effort into delivering the output buffers to the slaves, calling the write handler directly. This three changes are the result of many tests, I found (partially empirically) that is the best way to address the problem, but maybe we'll find better solutions in the future.
-
由 antirez 提交于
Initial version of c->reply_bytes implementation backported from unstable to 2.4, in order to apply issue 327 patches.
-
由 antirez 提交于
-
- 14 2月, 2012 1 次提交
-
-
由 antirez 提交于
needed when installing a new Redis version. Thanks to Scott Kevill. Fixes issue #335.
-
- 02 2月, 2012 5 次提交
- 16 1月, 2012 1 次提交
-
-
由 Salvatore Sanfilippo 提交于
Don't expire keys when loading an RDB after a SYNC
-
- 14 1月, 2012 1 次提交
-
-
由 Pieter Noordhuis 提交于
The cron is responsible for expiring keys. When keys are expired at load time, it is possible that the snapshot of a master node gets modified. This can in turn lead to inconsistencies in the data set. A more concrete example of this behavior follows. A user reported a slave that would show an monotonically increase input buffer length, shortly after completing a SYNC. Also, `INFO` output showed a single blocked client, which could only be the master link. Investigation showed that indeed the `BRPOP` command was fed by the master. This command can only end up in the stream of write operations when it did NOT block, and effectively executed `RPOP`. However, when the key involved in the `BRPOP` is expired BEFORE the command is executed, the client executing it will block. The client in this case, is the master link.
-
- 12 1月, 2012 4 次提交
- 11 1月, 2012 1 次提交
-
-
由 antirez 提交于
-
- 07 1月, 2012 2 次提交