1. 08 2月, 2012 1 次提交
  2. 07 2月, 2012 1 次提交
  3. 06 2月, 2012 1 次提交
  4. 04 2月, 2012 2 次提交
    • A
      This fixes issue #327, is a very complex fix (unfortunately), details: · f6b32c14
      antirez 提交于
      1) sendReplyToClient() now no longer stops transferring data to a single
      client in the case we are out of memory (maxmemory-wise).
      
      2) in processCommand() the idea of we being out of memory is no longer
      the naive zmalloc_used_memory() > server.maxmemory. To say if we can
      accept or not write queries is up to the return value of
      freeMemoryIfNeeded(), that has full control about that.
      
      3) freeMemoryIfNeeded() now does its math without considering output
      buffers size. But at the same time it can't let the output buffers to
      put us too much outside the max memory limit, so at the same time it
      makes sure there is enough effort into delivering the output buffers to
      the slaves, calling the write handler directly.
      
      This three changes are the result of many tests, I found (partially
      empirically) that is the best way to address the problem, but maybe
      we'll find better solutions in the future.
      f6b32c14
    • A
      Use less memory when emitting the protocol, by using more shared objects for... · 355f8591
      antirez 提交于
      Use less memory when emitting the protocol, by using more shared objects for commonly emitted parts of the protocol.
      355f8591
  5. 26 1月, 2012 1 次提交
  6. 24 1月, 2012 5 次提交
  7. 23 1月, 2012 1 次提交
  8. 17 1月, 2012 2 次提交
  9. 12 1月, 2012 1 次提交
  10. 31 12月, 2011 2 次提交
  11. 21 12月, 2011 1 次提交
  12. 19 12月, 2011 1 次提交
  13. 28 11月, 2011 1 次提交
  14. 25 11月, 2011 1 次提交
  15. 24 11月, 2011 3 次提交
  16. 21 11月, 2011 5 次提交
  17. 08 11月, 2011 3 次提交
  18. 04 11月, 2011 2 次提交
  19. 03 11月, 2011 2 次提交
  20. 02 11月, 2011 1 次提交
  21. 31 10月, 2011 1 次提交
  22. 17 10月, 2011 1 次提交
  23. 05 10月, 2011 1 次提交