- 16 Jul, 2018 2 commits
-
-
antirez authored
Reading the PR gave me the opportunity to better specify what the code was doing in places where I was not immediately sure about what was going on. Moreover I documented the structure in server.h so that people reading the header file will immediately understand what the structure is useful for.
-
Oran Agra authored
A) slave buffers didn't count internal fragmentation and sds unused space, this caused them to induce eviction although we didn't mean for it. B) slave buffers were consuming about twice the memory of what they actually needed. - this was mainly due to sdsMakeRoomFor growing to twice as much as needed each time but networking.c not storing more than 16k (partially fixed recently in 237a38737). - besides it wasn't able to store half of the new string into one buffer and the other half into the next (so the above mentioned fix helped mainly for small items). - lastly, the sds buffers had up to 30% internal fragmentation that was wasted, consumed but not used. C) inefficient performance due to starting from a small string and reallocing many times. what i changed: - creating dedicated buffers for reply list, counting their size with zmalloc_size - when creating a new reply node from, preallocate it to at least 16k. - when appending a new reply to the buffer, first fill all the unused space of the previous node before starting a new one. other changes: - expose mem_not_counted_for_evict info field for the benefit of the test suite - add a test to make sure slave buffers are counted correctly and that they don't cause eviction
-
- 09 Jul, 2018 3 commits
- 02 Jul, 2018 1 commit
-
-
antirez authored
-
- 29 Jun, 2018 1 commit
-
-
antirez authored
Making it more similar to KILL.
-
- 28 Jun, 2018 2 commits
-
-
zhaozhao.zz authored
-
zhaozhao.zz authored
-
- 27 Jun, 2018 6 commits
- 13 Jun, 2018 1 commit
-
-
zhaozhao.zz authored
-
- 07 Jun, 2018 1 commit
-
-
Itamar Haber authored
-
- 22 Mar, 2018 2 commits
- 15 Mar, 2018 2 commits
- 28 Feb, 2018 1 commit
-
-
antirez authored
Many thanks to @Plasma that spotted this problem reviewing the code.
-
- 27 Feb, 2018 1 commit
-
-
antirez authored
In case the write handler is already installed, it could happen that we serve the reply of a query in the same event loop cycle we received it, preventing beforeSleep() from guaranteeing that we do the AOF fsync before sending the reply to the client. The AE_BARRIER mechanism, introduced in a previous commit, prevents this problem. This commit makes actual use of this new feature to fix the bug.
-
- 13 Feb, 2018 1 commit
-
-
antirez authored
See #3832.
-
- 18 Jan, 2018 1 commit
-
-
Guy Benoish authored
When feeding the master with a high rate traffic the the slave's feed is much slower. This causes the replication buffer to grow (indefinitely) which leads to slave disconnection. The problem is that writeToClient() decides to stop writing after NET_MAX_WRITES_PER_EVENT writes (In order to be fair to clients). We should ignore this when the client is a slave. It's better if clients wait longer, the alternative is that the slave has no chance to stay in sync in this situation.
-
- 11 Jan, 2018 1 commit
-
-
antirez authored
Related to #4568.
-
- 29 Dec, 2017 2 commits
-
-
Oran Agra authored
-
Oran Agra authored
- protocol parsing (processMultibulkBuffer) was limitted to 32big positions in the buffer readQueryFromClient potential overflow - rioWriteBulkCount used int, although rioWriteBulkString gave it size_t - several places in sds.c that used int for string length or index. - bugfix in RM_SaveAuxField (return was 1 or -1 and not length) - RM_SaveStringBuffer was limitted to 32bit length
-
- 06 Dec, 2017 1 commit
-
-
antirez authored
The main change introduced by this commit is pretending that help arrays are more text than code, thus indenting them at level 0. This improves readability, and is an old practice when defining arrays of C strings describing text. Additionally a few useless return statements are removed, and the HELP subcommand capitalized when printed to the user.
-
- 05 Dec, 2017 3 commits
-
-
Itamar Haber authored
-
Itamar Haber authored
-
antirez authored
We have this operation in two places: when caching the master and when linking a new client after the client creation. By having an API for this we avoid incurring in errors when modifying one of the two places forgetting the other. The function is also a good place where to document why we cache the linked list node. Related to #4497 and #4210.
-
- 03 Dec, 2017 1 commit
-
-
Itamar Haber authored
-
- 01 Dec, 2017 2 commits
- 30 Nov, 2017 1 commit
-
-
zhaozhao.zz authored
-
- 28 Nov, 2017 1 commit
-
-
Itamar Haber authored
This adds a new `addReplyHelp` helper that's used by commands when returning a help text. The following commands have been touched: DEBUG, OBJECT, COMMAND, PUBSUB, SCRIPT and SLOWLOG. WIP Fix entry command table entry for OBJECT for HELP option. After #4472 the command may have just 2 arguments. Improve OBJECT HELP descriptions. See #4472. WIP 2 WIP 3
-
- 11 Jul, 2017 1 commit
-
-
antirez authored
See issue #3844 for more information.
-
- 05 Jul, 2017 1 commit
-
-
spinlock authored
-
- 04 Jul, 2017 1 commit
-
-
antirez authored
Redis clients need to have an instantaneous idea of the amount of memory they are consuming (if the number is not exact should at least be proportional to the actual memory usage). We do that adding and subtracting the SDS length when pushing / popping from the client->reply list. However it is quite simple to add bugs in such a setup, by not taking the objects in the list and the count in sync. For such reason, Redis has an assertion to track counts near 2^64: those are always the result of the counter wrapping around because we subtract more than we add. This commit adds the symmetrical assertion: when the list is empty since we sent everything, the reply_bytes count should be zero. Thanks to the new assertion it should be simple to also detect the other problem, where the count slowly increases because of over-counting. The assertion adds a conditional in the code that sends the buffer to the socket but should not create any measurable performance slowdown, listLength() just accesses a structure field, and this code path is totally dominated by write(2). Related to #4100.
-