1. 25 May, 2012 1 commit
    • antirez's avatar
      Four new persistence fields in INFO. A few renamed. · 33e1db36
      antirez authored
      The 'persistence' section of INFO output now contains additional four
      fields related to RDB and AOF persistence:
      
       rdb_last_bgsave_time_sec       Duration of latest BGSAVE in sec.
       rdb_current_bgsave_time_sec    Duration of current BGSAVE in sec.
       aof_last_rewrite_time_sec      Duration of latest AOF rewrite in sec.
       aof_current_rewrite_time_sec   Duration of current AOF rewrite in sec.
      
      The 'current' fields are set to -1 if a BGSAVE / AOF rewrite is not in
      progress. The 'last' fileds are set to -1 if no previous BGSAVE / AOF
      rewrites were performed.
      
      Additionally a few fields in the persistence section were renamed for
      consistency:
      
       changes_since_last_save -> rdb_changes_since_last_save
       bgsave_in_progress -> rdb_bgsave_in_progress
       last_save_time -> rdb_last_save_time
       last_bgsave_status -> rdb_last_bgsave_status
       bgrewriteaof_in_progress -> aof_rewrite_in_progress
       bgrewriteaof_scheduled -> aof_rewrite_scheduled
      
      After the renaming, fields in the persistence section start with rdb_ or
      aof_ prefix depending on the persistence method they describe.
      The field 'loading' and related fields are not prefixed because they are
      unique for both the persistence methods.
      33e1db36
  2. 24 May, 2012 1 commit
    • antirez's avatar
      Allow an AOF rewrite buffer > 2GB (Fix for issue #504). · 47ca4b6e
      antirez authored
      During the AOF rewrite process, the parent process needs to accumulate
      the new writes in an in-memory buffer: when the child will terminate the
      AOF rewriting process this buffer (that ist the difference between the
      dataset when the rewrite was started, and the current dataset) is
      flushed to the new AOF file.
      
      We used to implement this buffer using an sds.c string, but sds.c has a
      2GB limit. Sometimes the dataset can be big enough, the amount of writes
      so high, and the rewrite process slow enough that we overflow the 2GB
      limit, causing a crash, documented on github by issue #504.
      
      In order to prevent this from happening, this commit introduces a new
      system to accumulate writes, implemented by a linked list of blocks of
      10 MB each, so that we also avoid paying the reallocation cost.
      
      Note that theoretically modern operating systems may implement realloc()
      simply as a remaping of the old pages, thus with very good performances,
      see for instance the mremap() syscall on Linux. However this is not
      always true, and jemalloc by default avoids doing this because there are
      issues with the current implementation of mremap().
      
      For this reason we are using a linked list of blocks instead of a single
      block that gets reallocated again and again.
      
      The changes in this commit lacks testing, that will be performed before
      merging into the unstable branch. This fix will not enter 2.4 because it
      is too invasive. However 2.4 will log a warning when the AOF rewrite
      buffer is near to the 2GB limit.
      47ca4b6e
  3. 21 May, 2012 1 commit
    • antirez's avatar
      Use comments to split aof.c into sections. · 5a559993
      antirez authored
      This makes the code more readable, it is still not the case to split the
      file itself into three different files, but the logical separation
      improves the readability especially since new commits are going to
      introduce an additional section.
      5a559993
  4. 07 Apr, 2012 1 commit
  5. 27 Mar, 2012 1 commit
  6. 25 Mar, 2012 1 commit
    • antirez's avatar
      New INFO field aof_delayed_fsync introduced. · c1d01b3c
      antirez authored
      This new field counts all the times Redis is configured with AOF enabled and
      fsync policy 'everysec', but the previous fsync performed by the
      background thread was not able to complete within two seconds, forcing
      Redis to perform a write against the AOF file while the fsync is still
      in progress (likely a blocking operation).
      c1d01b3c
  7. 14 Mar, 2012 1 commit
  8. 10 Mar, 2012 1 commit
  9. 24 Jan, 2012 1 commit
  10. 23 Jan, 2012 1 commit
  11. 17 Jan, 2012 1 commit
  12. 03 Jan, 2012 1 commit
  13. 21 Dec, 2011 6 commits
  14. 20 Dec, 2011 1 commit
  15. 15 Dec, 2011 2 commits
  16. 13 Dec, 2011 5 commits
  17. 12 Nov, 2011 1 commit
  18. 10 Nov, 2011 1 commit
  19. 09 Nov, 2011 2 commits
  20. 08 Nov, 2011 1 commit
  21. 26 Oct, 2011 1 commit
  22. 08 Oct, 2011 1 commit
  23. 22 Sep, 2011 1 commit
  24. 19 Sep, 2011 2 commits
  25. 16 Sep, 2011 4 commits