- 04 12月, 2014 1 次提交
-
-
由 Alexis Campailla 提交于
Slave processes were not using the master process log file. On Unix this is relying on the server.logfile variable being available to the slave processes through fork(), and reopening the logfile in the slaves (on every log event). On Windows we don't use server.logfile and require an explicity call to setLogFile. I resorted to explicitly passing the logfile to the slaves as a command line argument, so the logfile argument (and logging) can be available to the slave before qfork and globals setup have completed. Writing to the same file atomically from multiple processes requires using CreateFile with FILE_APPEND_DATA, instead of fopen, which provides atomicity on Unix but not on Windows. Also changed the implementation to not reopen the logfile on every log event, and not flushing the file on every write. Performance is dramaticaly improved this way.
-
- 14 11月, 2014 1 次提交
-
-
由 unknown 提交于
-
- 09 11月, 2014 1 次提交
-
-
由 unknown 提交于
issue 182: provide docx file content as github markdown for easier reading for those without a .docx file viewer.
-
- 06 11月, 2014 2 次提交
- 29 10月, 2014 2 次提交
-
-
由 Jonathan Pickett 提交于
-
由 Jonathan Pickett 提交于
Using QueryPerformancecounter to measure latency in redis-benchmark.exe
-
- 24 10月, 2014 1 次提交
-
-
由 deepakv 提交于
Redis-benchmark on windows seems to be not able to calculate the time granularity in micro seconds. Came across this article http://msdn.microsoft.com/en-us/library/windows/desktop/dn553408(v=vs.85).aspx and updated the benchmark for latency measurements accordingly. Windows: Following is output from windows for micro seconds taken for each request. Where for any request taking less than 1 ms is being calculated as 0 redis-benchmark.exe -h <azurerediscache> -a pwd -c 1 -d 1024 -t get -n 10 0,0,0,0,0,0,0,0 Linux: src/redis-benchmark -h <azurerediscache> -a pwd -c 1 -d 1024 -t get -n 10 792,800,808,820,837,845,888,891,971,2498 After the change on windows now it shows following: 796,809,887,890,893,943,944,974
-
- 02 10月, 2014 2 次提交
-
-
由 jonathan pickett 提交于
-
由 jonathan pickett 提交于
I found a case where the temp-rewriteaof-old-xxxx.aof files were not being deleted. Added the _O_TEMPORARY flag to the open() call to guarantee that the underlying CreateFile call is being called with the FILE_FLAG_DELETE_ON_CLOSE.
-
- 24 9月, 2014 1 次提交
-
-
由 jonathan pickett 提交于
Restoring the ability to compile without IOCP. To do so remove the WIN32_IOCP definition in the C/C++\Preporcessor\Preprocessor Definitions in all projects. Performance is 30-40% better with IOCP.
-
- 22 9月, 2014 1 次提交
-
-
由 jonathan pickett 提交于
-
- 20 9月, 2014 2 次提交
-
-
由 jonathan pickett 提交于
Added a project to take current redis version number in src\version.h and propagate this number into the release documentation and the name of the release zip file. This replaces the powershell script used previously to build the binary release package zip.
-
由 jonathan pickett 提交于
-
- 19 9月, 2014 2 次提交
-
-
由 antirez 提交于
-
由 Matt Stancliff 提交于
Fixed in Redis by 1a5e5b6b, but since that part of code is largely copy/paste from Redis, the fix needs to be ported over too. Closes #2012
-
- 17 9月, 2014 2 次提交
-
-
由 jonathan pickett 提交于
-
由 jonathan pickett 提交于
-
- 16 9月, 2014 6 次提交
-
-
由 antirez 提交于
-
由 antirez 提交于
Now there are tests to write more data after loading a truncated AOF, testing that the loaded data is correct, appending more, and testing again.
-
由 antirez 提交于
It is not clear if files open in append only mode will automatically fix their offset after a truncate(2) operation. This commit makes sure that we reposition the AOF file descriptor offset at the end of the file after a truncated AOF is loaded and trimmed to the last valid command.
-
由 antirez 提交于
Recently we introduced the ability to load truncated AOFs, but unfortuantely the support was broken since the server, after loading the truncated AOF, continues appending to the file that is corrupted at the end. The problem is fixed only in the next AOF rewrite. This commit fixes the issue by truncating the AOF to the last valid opcode, and aborting if it is not possible to truncate the file correctly.
-
由 antirez 提交于
This is a general fix (check that dirty delta is positive) but actually should have as the only effect fixing the SAVE propagation to AOF and slaves.
-
由 jonathan pickett 提交于
-
- 12 9月, 2014 4 次提交
-
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
The code to check the number of voters was never updated to follow the new Sentinel specification, so the number of voters was computed using only the set of Sentinels that provided a vote. This means that there is a changing majority on partitions, even if usually the issue is not triggered because of the configured quorum check (what was broken was the other implicit check that requires anyway half of the known sentinels to agree in order to start a failover).
-
- 10 9月, 2014 7 次提交
-
-
由 antirez 提交于
As discussed in issue #1945.
-
由 xiaost 提交于
*SCAN will cause redis server to hang for seconds after millions of keys was deleted by SCAN/DEL pairs
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
The original implementation was modified in order to allow to selectively announce a different IP or port, and to rewrite the two options in the config file after a rewrite.
-
由 Dara Kong 提交于
There are instances such as EC2 where the bind address is private (behind a NAT) and cannot be accessible from WAN. https://groups.google.com/d/msg/redis-db/PVVvjO4nMd0/P3oWC036v3cJ
-
由 jonathan pickett 提交于
issue 166: master/slave sync with RDB > 2G. cause: off_t defined as long. longs are 4-bytes on x64 Windows. Redefined impacted vars as int64_t.
-
- 08 9月, 2014 5 次提交
-
-
由 antirez 提交于
-
由 antirez 提交于
When aof-load-truncated option was introduced, with a default of "yes", the past behavior of the server to abort with trunncated AOF changed, so we need to explicitly configure the tests to abort with truncated AOF by setting the option to no.
-
由 antirez 提交于
-
由 antirez 提交于
Because of the new ability to start with a truncated AOF, we need to correctly release all the memory on EOF error. Otherwise there is a small leak, that is not really a problem, but causes a false positive in the tests that detect memory leaks.
-
由 antirez 提交于
-