- 27 Feb, 2013 2 commits
-
-
Stam He authored
1) Add a check for aeCreateTimeEvent in function initServer.
-
Stam He authored
This cased a segfault in some Linux system and was GCC-specific. Commit modified by @antirez: 1) Stripped away the part to set the proc title via config for now. 2) Handle initialization of setproctitle only when the replacement is used. 3) Don't require GCC now that the attribute constructor is no longer used.
-
- 26 Feb, 2013 1 commit
-
-
antirez authored
This commit allows Redis to set a process name that includes the binding address and the port number in order to make operations simpler. Redis children processes doing AOF rewrites or RDB saving change the name into redis-aof-rewrite and redis-rdb-bgsave respectively. This in general makes harder to kill the wrong process because of an error and makes simpler to identify saving children. This feature was suggested by Arnaud GRANAL in the Redis Google Group, Arnaud also pointed me to the setproctitle.c implementation includeed in this commit. This feature should work on all the Linux, OSX, and all the three major BSD systems.
-
- 25 Feb, 2013 2 commits
- 20 Feb, 2013 1 commit
-
-
antirez authored
Also using this new flag the RESTORE-ASKING command was implemented that will be used by MIGRATE.
-
- 15 Feb, 2013 1 commit
-
-
antirez authored
-
- 14 Feb, 2013 1 commit
-
-
antirez authored
-
- 12 Feb, 2013 5 commits
-
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
SELECT was still transmitted to slaves using the inline protocol, that is conceived mostly for humans to type into telnet sessions, and is notably not understood by redis-cli --slave. Now the new protocol is used instead.
-
antirez authored
Before this commit every Redis slave had its own selected database ID state. This was not actually useful as the emitted stream of commands is identical for all the slaves. Now the the currently selected database is a global state that is set to -1 when a new slave is attached, in order to force the SELECT command to be re-emitted for all the slaves. This change is useful in order to implement replication partial resynchronization in the future, as makes sure that the stream of commands received by slaves, including SELECT commands, are exactly the same for every slave connected, at any time. In this way we could have a global offset that can identify a specific piece of the master -> slaves stream of commands.
-
- 08 Feb, 2013 1 commit
-
-
antirez authored
-
- 07 Feb, 2013 1 commit
-
-
antirez authored
-
- 05 Feb, 2013 2 commits
-
-
antirez authored
-
charsyam authored
Further details from @antirez: It was reported by @StopForumSpam on Twitter that the Redis replication link was strangely using multiple TCP packets for multiple commands. This wastes a lot of bandwidth and is due to the TCP_NODELAY option we enable on the socket after accepting a new connection. However the master -> slave channel is a one-way channel since Redis replication is asynchronous, so there is no point in trying to reduce the latency, we should aim to reduce the bandwidth. For this reason this commit introduces the ability to disable the nagle algorithm on the socket after a successful SYNC. This feature is off by default because the delay can be up to 40 milliseconds with normally configured Linux kernels.
-
- 28 Jan, 2013 4 commits
-
-
antirez authored
When keyspace events are enabled, the overhead is not sever but noticeable, so this commit introduces the ability to select subclasses of events in order to avoid to generate events the user is not interested in. The events can be selected using redis.conf or CONFIG SET / GET.
-
antirez authored
-
antirez authored
-
Pierre Chapuis authored
-
- 19 Jan, 2013 4 commits
-
-
antirez authored
This commit fixes issue #875 that was caused by the following events: 1) There is an active child doing BGSAVE. 2) flushall is called (or any other condition that makes Redis killing the saving child process). 3) An error is sensed by Redis as the child exited with an error (killed by a singal), that stops accepting write commands until a BGSAVE happens to be executed with success. Whitelisting SIGUSR1 and making sure Redis always uses this signal in order to kill its own children fixes the issue.
-
antirez authored
When a SIGTERM is received Redis schedules a shutdown. However if it fails to perform the shutdown it must be clear the shutdown_asap flag otehrwise it will try again and again possibly making the server unusable.
-
antirez authored
The Redis Slow Log always used to log the slow commands executed inside a MULTI/EXEC block. However also EXEC was logged at the end, which is perfectly useless. Now EXEC is no longer logged and a test was added to test this behavior. This fixes issue #759.
-
guiquanz authored
-
- 16 Jan, 2013 1 commit
-
-
Hu Weiwei authored
-
- 10 Jan, 2013 1 commit
-
-
antirez authored
-
- 14 Dec, 2012 1 commit
-
-
antirez authored
REDIS_HZ is the frequency our serverCron() function is called with. A more frequent call to this function results into less latency when the server is trying to handle very expansive background operations like mass expires of a lot of keys at the same time. Redis 2.4 used to have an HZ of 10. This was good enough with almost every setup, but the incremental key expiration algorithm was working a bit better under *extreme* pressure when HZ was set to 100 for Redis 2.6. However for most users a latency spike of 30 milliseconds when million of keys are expiring at the same time is acceptable, on the other hand a default HZ of 100 in Redis 2.6 was causing idle instances to use some CPU time compared to Redis 2.4. The CPU usage was in the order of 0.3% for an idle instance, however this is a shame as more energy is consumed by the server, if not important resources. This commit introduces HZ as a runtime parameter, that can be queried by INFO or CONFIG GET, and can be modified with CONFIG SET. At the same time the default frequency is set back to 10. In this way we default to a sane value of 10, but allows users to easily switch to values up to 500 for near real-time applications if needed and if they are willing to pay this small CPU usage penalty.
-
- 29 Nov, 2012 1 commit
-
-
antirez authored
The idea is to be able to identify a build in a unique way, so for instance after a bug report we can recognize that the build is the one of a popular Linux distribution and perform the debugging in the same environment.
-
- 22 Nov, 2012 2 commits
-
-
antirez authored
EVALSHA used to crash if the SHA1 was not lowercase (Issue #783). Fixed using a case insensitive dictionary type for the sha -> script map used for replication of scripts.
-
antirez authored
After the transcation starts with a MULIT, the previous behavior was to return an error on problems such as maxmemory limit reached. But still to execute the transaction with the subset of queued commands on EXEC. While it is true that the client was able to check for errors distinguish QUEUED by an error reply, MULTI/EXEC in most client implementations uses pipelining for speed, so all the commands and EXEC are sent without caring about replies. With this change: 1) EXEC fails if at least one command was not queued because of an error. The EXECABORT error is used. 2) A generic error is always reported on EXEC. 3) The client DISCARDs the MULTI state after a failed EXEC, otherwise pipelining multiple transactions would be basically impossible: After a failed EXEC the next transaction would be simply queued as the tail of the previous transaction.
-
- 12 Nov, 2012 1 commit
-
-
antirez authored
-
- 11 Nov, 2012 1 commit
-
-
antirez authored
By caching TCP connections used by MIGRATE to chat with other Redis instances a 5x performance improvement was measured with redis-benchmark against small keys. This can dramatically speedup cluster resharding and other processes where an high load of MIGRATE commands are used.
-
- 08 Nov, 2012 1 commit
-
-
antirez authored
-
- 07 Nov, 2012 2 commits
-
-
antirez authored
With COPY now MIGRATE does not remove the key from the source instance. With REPLACE it uses RESTORE REPLACE on the target host so that even if the key already eixsts in the target instance it will be overwritten. The options can be used together.
-
antirez authored
The REPLACE option deletes an existing key with the same name (if any) and materializes the new one. The default behavior without RESTORE is to return an error if a key already exists.
-
- 06 Nov, 2012 1 commit
-
-
antirez authored
So instead to reply with a generic error like: -ERR ... wrong kind of value ... now it replies with: -WRONGTYPE ... wrong kind of value ... This makes this particular error easy to check without resorting to (fragile) pattern matching of the error string (however the error string used to be consistent already). Client libraries should return a specific exeption type for this error. Most of the commit is about fixing unit tests.
-
- 01 Nov, 2012 2 commits
-
-
antirez authored
After the wait3() syscall we used to do something like that: if (pid == server.rdb_child_pid) { backgroundSaveDoneHandler(exitcode,bysignal); } else { .... } So the AOF rewrite was handled in the else branch without actually checking if the pid really matches. This commit makes the check explicit and logs at WARNING level if the pid returned by wait3() does not match neither the RDB or AOF rewrite child.
-
Yecheng Fu authored
-
- 22 Oct, 2012 1 commit
-
-
antirez authored
This was an important information missing from the INFO output in the replication section. It obviously reflects if the slave is read only or not.
-