- 02 Oct, 2019 1 commit
-
-
Oran Agra authored
It seeems that since I added the creation of the jemalloc thread redis sometimes fails to start with the following error: Inconsistency detected by ld.so: dl-tls.c: 493: _dl_allocate_tls_init: Assertion `listp->slotinfo[cnt].gen <= GL(dl_tls_generation)' failed! This seems to be due to a race bug in ld.so, in which TLS creation on the thread, collide with dlopen. Move the creation of BIO and jemalloc threads to after modules are loaded. plus small bugfix when trying to disable the jemalloc thread at runtime
-
- 02 Jun, 2019 1 commit
-
-
Oran Agra authored
jemalloc 5 doesn't immediately release memory back to the OS, instead there's a decaying mechanism, which doesn't work when there's no traffic (no allocations). this is most evident if there's no traffic after flushdb, the RSS will remain high. 1) enable jemalloc background purging 2) explicitly purge in flushdb
-
- 15 May, 2019 1 commit
-
-
antirez authored
CLIENT PAUSE may be used, in other contexts, for a long time making all the slaves time out. Better for now to be more specific about what should disable senidng PINGs. An alternative to that would be to virtually refresh the slave interactions when clients are paused, however for now I went for this more conservative solution.
-
- 13 May, 2019 1 commit
-
-
antirez authored
-
- 08 May, 2019 3 commits
-
-
Angus Pearson authored
Enlarge error buffer in redis-check-aof.c to remove compiler warning of output truncation through snprintf format string
-
yongman authored
-
唐权 authored
Hi, @antirez In the code, to get the size of ziplist, "unsigned int bytes = ZIPLIST_HEADER_SIZE+1;" is correct, but why not make it more readable and easy to understand
-
- 07 May, 2019 3 commits
-
-
zhaozhao.zz authored
-
stan011 authored
-
zhaozhao.zz authored
-
- 06 May, 2019 21 commits
-
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
Potentially it is possible that we get interleaved writes, even if serverLog() makes sure to write into a buffer and then use printf(), so even this should be ok. However in general POSIX guarantees that writing to the same file pointer object from multiple threads is safe. Anyway currently we *reopen* the file at each call, but for the standard output logging. The logging functions actually also access global configuration while performing the log (for instance in order to check the log level, the log filename and so forth), however dunring the I/O threads execution we cannot alter such shared state in any way.
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
Ubuntu authored
Now threads are stopped even when the connections drop immediately to zero, not allowing the networking code to detect the condition and stop the threads. serverCron() will handle that.
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
This is just an experiment for now, there are a couple of race conditions, mostly harmless for the performance gain experiment that this commit represents so far. The general idea here is to take Redis single threaded and instead fan-out on expansive kernel calls: write(2) in this case, but the same concept could be easily implemented for read(2) and protcol parsing. However just threading writes like in this commit, is enough to evaluate if the approach is sounding.
-
liaotonglang authored
sdsTest() defined in sds.c dit not match the call in server.c. remove it from REDIS_TEST, since test-sds defined in Makefile.
-
WuYunlong authored
-
- 05 May, 2019 1 commit
-
-
Yossi Gottlieb authored
-
- 29 Apr, 2019 1 commit
-
-
zhaozhao.zz authored
-
- 26 Apr, 2019 2 commits
-
-
vattezhang authored
-
vattezhang authored
-
- 24 Apr, 2019 1 commit
-
-
git-hulk authored
-
- 17 Apr, 2019 1 commit
-
-
chendianqiang authored
-
- 11 Apr, 2019 1 commit
-
-
James Rouzier authored
-
- 10 Apr, 2019 1 commit
-
-
antirez authored
-
- 09 Apr, 2019 1 commit
-
-
yongman authored
-