• Wang Yuan's avatar
    Use madvise(MADV_DONTNEED) to release memory to reduce COW (#8974) · d4bca53c
    Wang Yuan authored
    
    
    ## Backgroud
    As we know, after `fork`, one process will copy pages when writing data to these
    pages(CoW), and another process still keep old pages, they totally cost more memory.
    For redis, we suffered that redis consumed much memory when the fork child is serializing
    key/values, even that maybe cause OOM.
    
    But actually we find, in redis fork child process, the child process don't need to keep some
    memory and parent process may write or update that, for example, child process will never
    access the key-value that is serialized but users may update it in parent process.
    So we think it may reduce COW if the child process release memory that it is not needed.
    
    ## Implementation
    For releasing key value in child process, we may think we call `decrRefCount` to free memory,
    but i find the fork child process still use much memory when we don't write any data to redis,
    and it costs much more time that slows down bgsave. Maybe because memory allocator doesn't
    really release memory to OS, and it may modify some inner data for this free operation, especially
    when we free small objects.
    
    Moreover, CoW is based on  pages, so it is a easy way that we only free the memory bulk that is
    not less than kernel page size. madvise(MADV_DONTNEED) can quickly release specified region
    pages to OS bypassing memory allocator, and allocator still consider that this memory still is used
    and don't change its inner data.
    
    There are some buffers we can release in the fork child process:
    - **Serialized key-values**
      the fork child process never access serialized key-values, so we try to free them.
      Because we only can release big bulk memory, and it is time consumed to iterate all
      items/members/fields/entries of complex data type. So we decide to iterate them and
      try to release them only when their average size of item/member/field/entry is more
      than page size of OS.
    - **Replication backlog**
      Because replication backlog is a cycle buffer, it will be changed quickly if redis has heavy
      write traffic, but in fork child process, we don't need to access that.
    - **Client buffers**
      If clients have requests during having the fork child process, clients' buffer also be changed
      frequently. The memory includes client query buffer, output buffer, and client struct used memory.
    
    To get child process peak private dirty memory, we need to count peak memory instead
    of last used memory, because the child process may continue to release memory (since
    COW used to only grow till now, the last was equivalent to the peak).
    Also we're adding a new `current_cow_peak` info variable (to complement the existing
    `current_cow_size`)
    Co-authored-by: default avatarOran Agra <oran@redislabs.com>
    d4bca53c
test_helper.tcl 26.9 KB