- 14 May, 2012 1 commit
-
-
antirez authored
Redis uses a function called serverCron() that is very similar to the timer interrupt of an operating system. This function is used to handle a number of asynchronous things, like active expired keys collection, clients timeouts, update of statistics, things related to the cluster and replication, triggering of BGSAVE and AOF rewrite process, and so forth. In the past the timer was called 1 time per second. At some point it was raised to 10 times per second, but it still was fixed and could not be changed even at compile time, because different functions called from serverCron() assumed a given fixed frequency. This commmit makes the frequency configurable, so that it is simpler to pick a good tradeoff between overhead of this function (that is usually very small) and the responsiveness of Redis during a few critical circumstances where a lot of work is done inside the timer. An example of such a critical condition is mass-expire of a lot of keys in the same second. Up to a given percentage of CPU time is used to perform expired keys collection per expire cylce. Now changing the REDIS_HZ macro it is possible to do less work but more times per second in order to block the server for less time. If this patch will work well in our tests it will enter Redis 2.6-final.
-
- 12 May, 2012 6 commits
-
-
antirez authored
-
antirez authored
If a large amonut of keys are all expiring about at the same time, the "active" expired keys collection cycle used to block as far as the percentage of already expired keys was >= 25% of the total population of keys with an expire set. This could block the server even for many seconds in order to reclaim memory ASAP. The new algorithm uses at max a small amount of milliseconds per cycle, even if this means reclaiming the memory less promptly it also means a more responsive server.
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
- 09 May, 2012 2 commits
- 06 May, 2012 4 commits
-
-
antirez authored
-
antirez authored
-
antirez authored
-
Salvatore Sanfilippo authored
Compare integers in ziplist regardless of encoding
-
- 05 May, 2012 1 commit
-
-
Pieter Noordhuis authored
Because of the introduction of new integer encoding types for ziplists in the 2.6 tree, the same integer value may have a different encoding in different versions of the ziplist implementation. This means that the encoding can NOT be used as a fast path in comparing integers.
-
- 04 May, 2012 1 commit
-
-
quiver authored
- PIDFILE environ variable was not properly retrieved - chkconfig command failed
-
- 02 May, 2012 6 commits
-
-
antirez authored
The new implementation start reading / writing before blocking with aeWait(), likely the descriptor can accept writes or has buffered data inside and we can go faster, otherwise we get an error and wait. This change has effects on speed but also on correctness: on socket errors when we perform non blocking connect(2) write is performed ASAP and the error is returned ASAP before waiting. So the practical effect is that now a Redis slave is more available if it can not connect to the master, previously the slave continued to block on syncWrite() trying to send SYNC, and serving commands very slowly.
-
antirez authored
-
antirez authored
We used to reply -ERR ... message ..., now the reply is instead -MASTERDOWN ... message ... so that it can be distinguished easily by the other error conditions.
-
antirez authored
-
antirez authored
-
antirez authored
-
- 01 May, 2012 1 commit
-
-
Salvatore Sanfilippo authored
Use safe dictionary iterator from KEYS (fixes #487)
-
- 30 Apr, 2012 3 commits
-
-
Pieter Noordhuis authored
Every matched key in a KEYS call is checked for expiration. When the key is set to expire, the call to `getExpire` will assert that the key also exists in the main dictionary. This in turn causes a rehashing step to be executed. Rehashing a dictionary when there is an iterator active may result in the iterator emitting duplicate entries, or not emitting some entries at all. By using a safe iterator, the rehash step is omitted.
-
Harmen authored
-
antirez authored
-
- 29 Apr, 2012 1 commit
-
-
antirez authored
-
- 27 Apr, 2012 14 commits
-
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
An user reported a crash with Redis scripting (see issue #480 on github), inspection of the kindly provided strack trace showed that server.lua_caller was probably set to NULL. The stack trace also slowed that the call to the hook was originating from a point where we just used to set/get a few global variables in the Lua state. What was happening is that we did not set the timeout hook selectively only when the user script was called. Now we set it more selectively, specifically only in the context of the lua_pcall() call, and make sure to remove the hook when the call returns. Otherwise the hook can get called in random contexts every time we do something with the Lua state.
-
antirez authored
A previous commit removed -g -rdynamic -ggdb as LDFLAGS, not allowing Redis to produce a stack trace wth symbol names on crash. This commit fixes the issue.
-
antirez authored
-
antirez authored
This commit reverts most of c5757662, in order to use back main stack for signal handling. The main reason is that otherwise it is completely pointless that we do a lot of efforts to print the stack trace on crash, and the content of the stack and registers as well. Using an alternate stack broken this feature completely.
-
antirez authored
Now it uses the new wait_for_condition testing primitive. Also wait_for_condition implementation was fixed in this commit to properly escape the expr command and its argument.
-
antirez authored
A new primitive wait_for_condition was introduced in the scripting engine that makes waiting for events simpler, so that it is simpler to write tests that are more resistant to timing issues.
-