Uploaded image for project: 'Couchbase Server'
  1. Couchbase Server
  2. MB-50771

Working set tracking for in-memory compression

    XMLWordPrintable

Details

    • Improvement
    • Status: Open
    • Major
    • Resolution: Unresolved
    • 7.1.0
    • Morpheus
    • storage-engine
    • 1

    Description

      Plasma turns on in-memory compression only when memory usage is close to quota. In-memory compression can slow down scan throughput due to decompression cost during scan. In cases where scan working set is within quota but the overall memory use is close to quota, scan pages can still get compressed.

      One way to fix this issue is to track memory stats used by working set. In plasma, the working set are the pages with InUse bit being set. When a page is being used by mutation or scan, the page is marked as InUse. The swapper (eviction) is responsible for resetting the InUse bit as it sweeps through the pages.

      As the swapper resets the bit, it will compress the page (if uncompressed). As the page is compressed, the swapper can calculate the memory (pre-compressed) consumed by this page. We can then adjust the working set memory stats by subtracting the memory of this page.

      As the swapper resets the bit and the page is already compressed, we need to get the memory consumed by the page from compressDelta.

      When a compressed page being marked in-use, we will need to add the memory back to working set stats.

      Currently, for burst eviction, we do not compress a page when inUse bit is reset. We will either have to compress unused page during burst eviction or find another mean to track page memory.

      Attachments

        Issue Links

          No reviews matched the request. Check your Options in the drop-down menu of this sections header.

          Activity

            Another approach to consider is to at cache_hit_ratio and compress_cache_hit_ratio and decide whether to decompress for scan. For best latencies, we want to maintain as much of data as possible in memory and keep as much of it as possible decompressed. For this, we need to try to maximize cache_hit_ratio and minimize compress_cache_hit_ratio. If cache_hit_ratio is low, it means swapper is not able to keep working set in quota and it is better to keep things as compressed as possible. If cache_hit_ratio is high, it means swapper is able to keep working set in memory. In this case, if compress_cache_hit_ratio is also high, it means that we may have compressed the working set unnecessarily and tryPageSwapin should decompress the page.

            akhil.mundroy Akhil Mundroy added a comment - Another approach to consider is to at cache_hit_ratio and compress_cache_hit_ratio and decide whether to decompress for scan. For best latencies, we want to maintain as much of data as possible in memory and keep as much of it as possible decompressed. For this, we need to try to maximize cache_hit_ratio and minimize compress_cache_hit_ratio. If cache_hit_ratio is low, it means swapper is not able to keep working set in quota and it is better to keep things as compressed as possible. If cache_hit_ratio is high, it means swapper is able to keep working set in memory. In this case, if compress_cache_hit_ratio is also high, it means that we may have compressed the working set unnecessarily and tryPageSwapin should decompress the page.
            jliang John Liang added a comment - - edited

            Cache_hit_ratio is just a hint, it is not sufficient to indicate if the working set is in memory. In other words, cache hit ratio only tell whether the percentage of application traffic is accessing the resident working set, but it does not tell us whether the system is under memory pressure because the working set is too large to fit in. For example, when the working set shifts, cache hit ratio will drop, even though there is still memory to hold the working set. It can be hard to determine the threshold that is considered as "low" cache hit ratio. If it is set too high, you will end up compressing the working set. If it is set too low, it is ineffective. The net effect is that it is hard to predict when compression will kick in. It will be good to have an algorithm that is more predictable.

            jliang John Liang added a comment - - edited Cache_hit_ratio is just a hint, it is not sufficient to indicate if the working set is in memory. In other words, cache hit ratio only tell whether the percentage of application traffic is accessing the resident working set, but it does not tell us whether the system is under memory pressure because the working set is too large to fit in. For example, when the working set shifts, cache hit ratio will drop, even though there is still memory to hold the working set. It can be hard to determine the threshold that is considered as "low" cache hit ratio. If it is set too high, you will end up compressing the working set. If it is set too low, it is ineffective. The net effect is that it is hard to predict when compression will kick in. It will be good to have an algorithm that is more predictable.

            People

              jliang John Liang
              jliang John Liang
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:

                Gerrit Reviews

                  There are no open Gerrit changes

                  PagerDuty