1. 28 Apr, 2021 2 commits
    • Binbin's avatar
      redis-benchmark: Add zfree(data) and fix lrange size / text mismatch (#8872) · 1eff8564
      Binbin authored
      missing zfree(data) in redis-benchmark.
      
      And also correct the wrong size in lrange.
      the text mentioned 500, but size was 450, changed to 500
      1eff8564
    • filipe oliveira's avatar
      redis-benchmark: Error/Warning handling updates. (#8869) · ef6f9023
      filipe oliveira authored
      - Immediately exit on errors that are not related to topology updates.
      - Deprecates the `-e` option ( retro compatible ) and warns that we now
        exit immediately on errors that are not related to topology updates.
      - Fixed wrongfully failing on config fetch error (warning only). This only affects RE.
      
      Bottom line:
      - MOVED and ASK errors will not show any warning (unlike the throttled error with `-e` before).
      - CLUSTERDOWN still prints an error unconditionally and sleeps for 1 second.
      - other errors are fatal.
      ef6f9023
  2. 26 Apr, 2021 1 commit
    • Andy Pan's avatar
      Fail fast when systemic error occurs in poll (#8749) · a8b6596d
      Andy Pan authored
      Most of the ae.c backends didn't explicitly handle errors, and instead
      ignored all errors and did an implicit retry.
      This is desired for EAGAIN and EINTER, but in case of other systematic
      errors, we prefer to fail and log the error we got rather than get into a busy loop.
      a8b6596d
  3. 25 Apr, 2021 1 commit
  4. 09 Mar, 2021 1 commit
  5. 05 Mar, 2021 1 commit
  6. 14 Feb, 2021 1 commit
  7. 07 Feb, 2021 1 commit
  8. 23 Dec, 2020 1 commit
    • Greg Femec's avatar
      Fix random element selection for large hash tables. (#8133) · 266949c7
      Greg Femec authored
      
      
      When a database on a 64 bit build grows past 2^31 keys, the underlying hash table expands to 2^32 buckets. After this point, the algorithms for selecting random elements only return elements from half of the available buckets because they use random() which has a range of 0 to 2^31 - 1. This causes problems for eviction policies which use dictGetSomeKeys or dictGetRandomKey. Over time they cause the hash table to become unbalanced because, while new keys are spread out evenly across all buckets, evictions come from only half of the available buckets. Eventually this half of the table starts to run out of keys and it takes longer and longer to find candidates for eviction. This continues until no more evictions can happen.
      
      This solution addresses this by using a 64 bit PRNG instead of libc random().
      Co-authored-by: default avatarGreg Femec <gfemec@google.com>
      266949c7
  9. 17 Dec, 2020 1 commit
    • Wang Yuan's avatar
      [Redis-benchmark] Use IP from CLUSTER NODE reply for first node too (#8154) · 6413e5f8
      Wang Yuan authored
      If we only has one node in cluster or before 8fdc857a, we don't know myself ip, so we should use config.hostip for myself.
      However, we should use the IP from the command response to update node->ip if it exists and is different from config.hostip
      
      otherwise, when there's more than one node in cluster, if we use -h with virtual IP or DNS, benchmark doesn't show node real ip and port of myself even though it could get right IP and port by CLUSTER NODES command.
      6413e5f8
  10. 13 Dec, 2020 1 commit
    • gourav's avatar
      Randomize the random number generator's seed used in redis-benchmark (#8174) · ddd43b6b
      gourav authored
      The pid of the benchmark process is used to randomize the random number generator's
      seed. This ensures that when multiple benchmark processes are started at the same time
      to generate load on a server, they use different seeds. This will ensure randomness in
      the keys generated by different benchmark processes.
      ddd43b6b
  11. 06 Dec, 2020 1 commit
    • Wang Yuan's avatar
      Limit the main db and expires dictionaries to expand (#7954) · 75f9dec6
      Wang Yuan authored
      As we know, redis may reject user's requests or evict some keys if
      used memory is over maxmemory. Dictionaries expanding may make
      things worse, some big dictionaries, such as main db and expires dict,
      may eat huge memory at once for allocating a new big hash table and be
      far more than maxmemory after expanding.
      There are related issues: #4213 #4583
      
      More details, when expand dict in redis, we will allocate a new big
      ht[1] that generally is double of ht[0], The size of ht[1] will be
      very big if ht[0] already is big. For db dict, if we have more than
      64 million keys, we need to cost 1GB for ht[1] when dict expands.
      
      If the sum of used memory and new hash table of dict needed exceeds
      maxmemory, we shouldn't allow the dict to expand. Because, if we
      enable keys eviction, we still couldn't add much more keys after
      eviction and rehashing, what's worse, redis will keep less keys when
      redis only remains a little memory for storing new hash table instead
      of users' data. Moreover users can't write data in redis if disable
      keys eviction.
      
      What this commit changed ?
      
      Add a new member function expandAllowed for dict type, it provide a way
      for caller to allow expand or not. We expose two parameters for this
      function: more memory needed for expanding and dict current load factor,
      users can implement a function to make a decision by them.
      For main db dict and expires dict type, these dictionaries may be very
      big and cost huge memory for expanding, so we implement a judgement
      function: we can stop dict to expand provisionally if used memory will
      be over maxmemory after dict expands, but to guarantee the performance
      of redis, we still allow dict to expand if dict load factor exceeds the
      safe load factor.
      Add test cases to verify we don't allow main db to expand when left
      memory is not enough, so that avoid keys eviction.
      
      Other changes:
      
      For new hash table size when expand. Before this commit, the size is
      that double used of dict and later _dictNextPower. Actually we aim to
      control a dict load factor between 0.5 and 1.0. Now we replace *2 with
      +1, since the first check is that used >= size, the outcome of before
      will usually be the same as _dictNextPower(used+1). The only case where
      it'll differ is when dict_can_resize is false during fork, so that later
      the _dictNextPower(used*2) will cause the dict to jump to *4 (i.e.
      _dictNextPower(1025*2) will return 4096).
      Fix rehash test cases due to changing algorithm of new hash table size
      when expand.
      75f9dec6
  12. 02 Dec, 2020 1 commit
    • luhuachao's avatar
      Modify help msg PING_BULK to PING_MBULK in benchmark (#8109) · 7885faf1
      luhuachao authored
      As described in redis-benchamrk help message 'The test names are the same as the ones produced as output.', In redis-benchmark output, we can only see PING_BULK, but the cmd `redis-benchmark -t ping_bulk` is not supported. We  have to run it with ping_mbulk which is not user friendly.
      7885faf1
  13. 04 Nov, 2020 1 commit
  14. 28 Oct, 2020 1 commit
  15. 26 Oct, 2020 1 commit
  16. 20 Oct, 2020 1 commit
  17. 17 Sep, 2020 1 commit
    • Wang Yuan's avatar
      Implement redisAtomic to replace _Atomic C11 builtin (#7707) · 445a4b66
      Wang Yuan authored
      Redis 6.0 introduces I/O threads, it is so cool and efficient, we use C11
      _Atomic to establish inter-thread synchronization without mutex. But the
      compiler that must supports C11 _Atomic can compile redis code, that brings a
      lot of inconvenience since some common platforms can't support by default such
      as CentOS7, so we want to implement redis atomic type to make it more portable.
      
      We have implemented our atomic variable for redis that only has 'relaxed'
      operations in src/atomicvar.h, so we implement some operations with
      'sequentially-consistent', just like the default behavior of C11 _Atomic that
      can establish inter-thread synchronization. And we replace all uses of C11
      _Atomic with redis atomic variable.
      
      Our implementation of redis atomic variable uses C11 _Atomic, __atomic or
      __sync macros if available, it supports most common platforms, and we will
      detect automatically which feature we use. In Makefile we use a dummy file to
      detect if the compiler supports C11 _Atomic. Now for gcc, we can compile redis
      code theoretically if your gcc version is not less than 4.1.2(starts to support
      __sync_xxx operations). Otherwise, we remove use mutex fallback to implement
      redis atomic variable for performance and test. You will get compiling errors
      if your compiler doesn't support all features of above.
      
      For cover redis atomic variable tests, we add other CI jobs that build redis on
      CentOS6 and CentOS7 and workflow daily jobs that run the tests on them.
      For them, we just install gcc by default in order to cover different compiler
      versions, gcc is 4.4.7 by default installation on CentOS6 and 4.8.5 on CentOS7.
      
      We restore the feature that we can test redis with Helgrind to find data race
      errors. But you need install Valgrind in the default path configuration firstly
      before running your tests, since we use macros in helgrind.h to tell Helgrind
      inter-thread happens-before relationship explicitly for avoiding false positives.
      Please open an issue on github if you find data race errors relate to this commit.
      
      Unrelated:
      - Fix redefinition of typedef 'RedisModuleUserChangedFunc'
        For some old version compilers, they will report errors or warnings, if we
        re-define function type.
      445a4b66
  18. 25 Aug, 2020 1 commit
  19. 15 Aug, 2020 1 commit
  20. 11 Aug, 2020 1 commit
  21. 08 Aug, 2020 1 commit
  22. 06 Aug, 2020 1 commit
  23. 10 Jul, 2020 1 commit
  24. 19 May, 2020 1 commit
  25. 18 May, 2020 1 commit
  26. 05 May, 2020 1 commit
  27. 04 May, 2020 1 commit
  28. 22 Jul, 2019 1 commit
  29. 05 Jun, 2019 1 commit
  30. 26 Apr, 2019 2 commits
  31. 24 Apr, 2019 1 commit
  32. 08 Apr, 2019 1 commit
  33. 13 Mar, 2019 1 commit
  34. 12 Mar, 2019 1 commit
  35. 08 Mar, 2019 1 commit
  36. 07 Mar, 2019 2 commits
  37. 01 Mar, 2019 1 commit