Does redis-port support starting as windows service? #1
Comments
|
You would have to write some code in order to do it now. For the next release we plan to build a wrapper to spawn the redis-server process so it can run as Windows service. |
|
Redis-watcher is what you need. It is a WIndows service that can start one or more redis instances and restart the processes if they stops. you can find a readme with the instructions on how to use it under the msvs/redis-watcher directory |
|
@clca when I try to start RedisWatcherSvc, I am getting the following error:
The service is installed properly but there is a problem when I try to start it. The OS I installed the service is Windows Server 2008 R2 and there is nothing else installed on this server (no role, no feature and anything else). |
|
@clca ok, I just installed Microsoft Visual C++ 2010 Redistributable Package and it solved the problem. I think it might be helpful if you guys can put this inside readme. |
|
thanks for reporting this issue, it is a bug, we forgot to set the flag in VS to include the C++ libraries in the binary. |
|
@clca perfect! thanks a lot. |
|
this seems to be resolved, feel free to reopen the issue if you find other issues with the Redis-Watcher service. |
The main idea here is that when we are no longer to expire keys at the
rate the are created, we can't block more in the normal expire cycle as
this would result in too big latency spikes.
For this reason the commit introduces a "fast" expire cycle that does
not run for more than 1 millisecond but is called in the beforeSleep()
hook of the event loop, so much more often, and with a frequency bound
to the frequency of executed commnads.
The fast expire cycle is only called when the standard expiration
algorithm runs out of time, that is, consumed more than
REDIS_EXPIRELOOKUPS_TIME_PERC of CPU in a given cycle without being able
to take the number of already expired keys that are yet not collected
to a number smaller than 25% of the number of keys.
You can test this commit with different loads, but a simple way is to
use the following:
Extreme load with pipelining:
redis-benchmark -r 100000000 -n 100000000 \
-P 32 set ele:rand:000000000000 foo ex 2
Remove the -P32 in order to avoid the pipelining for a more real-world
load.
In another terminal tab you can monitor the Redis behavior with:
redis-cli -i 0.1 -r -1 info keyspace
and
redis-cli --latency-history
Note: this commit will make Redis printing a lot of debug messages, it
is not a good idea to use it in production.
The bug could be easily triggered by:
SADD foo a b c 1 2 3 4 5 6
SDIFF foo foo
When the key was the same in two sets, an unsafe iterator was used to
check existence of elements in the same set we were iterating.
Usually this would just result into a wrong output, however with the
dict.c API misuse protection we have in place, the result was actually
an assertion failed that was triggered by the CI test, while creating
random datasets for the "MASTER and SLAVE consistency" test.
The main idea here is that when we are no longer to expire keys at the
rate the are created, we can't block more in the normal expire cycle as
this would result in too big latency spikes.
For this reason the commit introduces a "fast" expire cycle that does
not run for more than 1 millisecond but is called in the beforeSleep()
hook of the event loop, so much more often, and with a frequency bound
to the frequency of executed commnads.
The fast expire cycle is only called when the standard expiration
algorithm runs out of time, that is, consumed more than
REDIS_EXPIRELOOKUPS_TIME_PERC of CPU in a given cycle without being able
to take the number of already expired keys that are yet not collected
to a number smaller than 25% of the number of keys.
You can test this commit with different loads, but a simple way is to
use the following:
Extreme load with pipelining:
redis-benchmark -r 100000000 -n 100000000 \
-P 32 set ele:rand:000000000000 foo ex 2
Remove the -P32 in order to avoid the pipelining for a more real-world
load.
In another terminal tab you can monitor the Redis behavior with:
redis-cli -i 0.1 -r -1 info keyspace
and
redis-cli --latency-history
Note: this commit will make Redis printing a lot of debug messages, it
is not a good idea to use it in production.
```sh $ ~ pidof redis-server # nothing $ ~ ps aux | grep [r]edis redis 593 0.0 0.0 36900 5564 ? Ssl Dec02 1:37 /usr/bin/redis-server 127.0.0.1:6379 klay 15927 0.0 0.0 16772 6068 pts/6 S+ 13:58 0:00 redis-cli $ ~ uname -a Linux edge 3.17.4-1-ARCH #1 SMP PREEMPT Fri Nov 21 21:14:42 CET 2014 x86_64 GNU/Linux ```
```sh $ ~ pidof redis-server # nothing $ ~ ps aux | grep [r]edis redis 593 0.0 0.0 36900 5564 ? Ssl Dec02 1:37 /usr/bin/redis-server 127.0.0.1:6379 klay 15927 0.0 0.0 16772 6068 pts/6 S+ 13:58 0:00 redis-cli $ ~ uname -a Linux edge 3.17.4-1-ARCH #1 SMP PREEMPT Fri Nov 21 21:14:42 CET 2014 x86_64 GNU/Linux ```
Is it possible to install redis-server.exe as windows service? How?
The text was updated successfully, but these errors were encountered: