|
| 1 | +# Background Data Movement |
| 2 | + |
| 3 | +In order to reduce the number of online evictions and support asynchronous |
| 4 | +promotion - we have added two periodic workers to handle eviction and promotion. |
| 5 | + |
| 6 | +The diagram below shows a simplified version of how the background evictor |
| 7 | +thread (green) is integrated to the CacheLib architecture. |
| 8 | + |
| 9 | +<p align="center"> |
| 10 | + <img width="640" height="360" alt="BackgroundEvictor" src="cachelib-background-evictor.png"> |
| 11 | +</p> |
| 12 | + |
| 13 | +## Synchronous Eviction and Promotion |
| 14 | + |
| 15 | +- `disableEvictionToMemory`: Disables eviction to memory (item is always evicted to NVMe or removed |
| 16 | +on eviction) |
| 17 | + |
| 18 | +## Background Evictors |
| 19 | + |
| 20 | +The background evictors scan each class to see if there are objects to move the next (lower) |
| 21 | +tier using a given strategy. Here we document the parameters for the different |
| 22 | +strategies and general parameters. |
| 23 | + |
| 24 | +- `backgroundEvictorIntervalMilSec`: The interval that this thread runs for - by default |
| 25 | +the background evictor threads will wake up every 10 ms to scan the AllocationClasses. Also, |
| 26 | +the background evictor thead will be woken up everytime there is a failed allocation (from |
| 27 | +a request handling thread) and the current percentage of free memory for the |
| 28 | +AllocationClass is lower than `lowEvictionAcWatermark`. This may render the interval parameter |
| 29 | +not as important when there are many allocations occuring from request handling threads. |
| 30 | + |
| 31 | +- `evictorThreads`: The number of background evictors to run - each thread is a assigned |
| 32 | +a set of AllocationClasses to scan and evict objects from. Currently, each thread gets |
| 33 | +an equal number of classes to scan - but as object size distribution may be unequal - future |
| 34 | +versions will attempt to balance the classes among threads. The range is 1 to number of AllocationClasses. |
| 35 | +The default is 1. |
| 36 | + |
| 37 | +- `maxEvictionBatch`: The number of objects to remove in a given eviction call. The |
| 38 | +default is 40. Lower range is 10 and the upper range is 1000. Too low and we might not |
| 39 | +remove objects at a reasonable rate, too high and it might increase contention with user threads. |
| 40 | + |
| 41 | +- `minEvictionBatch`: Minimum number of items to evict at any time (if there are any |
| 42 | +candidates) |
| 43 | + |
| 44 | +- `maxEvictionPromotionHotness`: Maximum candidates to consider for eviction. This is similar to `maxEvictionBatch` |
| 45 | +but it specifies how many candidates will be taken into consideration, not the actual number of items to evict. |
| 46 | +This option can be used to configure duration of critical section on LRU lock. |
| 47 | + |
| 48 | + |
| 49 | +### FreeThresholdStrategy (default) |
| 50 | + |
| 51 | +- `lowEvictionAcWatermark`: Triggers background eviction thread to run |
| 52 | +when this percentage of the AllocationClass is free. |
| 53 | +The default is `2.0`, to avoid wasting capacity we don't set this above `10.0`. |
| 54 | + |
| 55 | +- `highEvictionAcWatermark`: Stop the evictions from an AllocationClass when this |
| 56 | +percentage of the AllocationClass is free. The default is `5.0`, to avoid wasting capacity we |
| 57 | +don't set this above `10`. |
| 58 | + |
| 59 | + |
| 60 | +## Background Promoters |
| 61 | + |
| 62 | +The background promotes scan each class to see if there are objects to move to a lower |
| 63 | +tier using a given strategy. Here we document the parameters for the different |
| 64 | +strategies and general parameters. |
| 65 | + |
| 66 | +- `backgroundPromoterIntervalMilSec`: The interval that this thread runs for - by default |
| 67 | +the background promoter threads will wake up every 10 ms to scan the AllocationClasses for |
| 68 | +objects to promote. |
| 69 | + |
| 70 | +- `promoterThreads`: The number of background promoters to run - each thread is a assigned |
| 71 | +a set of AllocationClasses to scan and promote objects from. Currently, each thread gets |
| 72 | +an equal number of classes to scan - but as object size distribution may be unequal - future |
| 73 | +versions will attempt to balance the classes among threads. The range is `1` to number of AllocationClasses. The default is `1`. |
| 74 | + |
| 75 | +- `maxProtmotionBatch`: The number of objects to promote in a given promotion call. The |
| 76 | +default is 40. Lower range is 10 and the upper range is 1000. Too low and we might not |
| 77 | +remove objects at a reasonable rate, too high and it might increase contention with user threads. |
| 78 | + |
| 79 | +- `minPromotionBatch`: Minimum number of items to promote at any time (if there are any |
| 80 | +candidates) |
| 81 | + |
| 82 | +- `numDuplicateElements`: This allows us to promote items that have existing handles (read-only) since |
| 83 | +we won't need to modify the data when a user is done with the data. Therefore, for a short time |
| 84 | +the data could reside in both tiers until it is evicted from its current tier. The default is to |
| 85 | +not allow this (0). Setting the value to 100 will enable duplicate elements in tiers. |
| 86 | + |
| 87 | +### Background Promotion Strategy (only one currently) |
| 88 | + |
| 89 | +- `promotionAcWatermark`: Promote items if there is at least this |
| 90 | +percent of free AllocationClasses. Promotion thread will attempt to move `maxPromotionBatch` number of objects |
| 91 | +to that tier. The objects are chosen from the head of the LRU. The default is `4.0`. |
| 92 | +This value should correlate with `lowEvictionAcWatermark`, `highEvictionAcWatermark`, `minAcAllocationWatermark`, `maxAcAllocationWatermark`. |
| 93 | +- `maxPromotionBatch`: The number of objects to promote in batch during BG promotion. Analogous to |
| 94 | +`maxEvictionBatch`. It's value should be lower to decrease contention on hot items. |
| 95 | + |
| 96 | +## Allocation policies |
| 97 | + |
| 98 | +- `maxAcAllocationWatermark`: Item is always allocated in topmost tier if at least this |
| 99 | +percentage of the AllocationClass is free. |
| 100 | +- `minAcAllocationWatermark`: Item is always allocated in bottom tier if only this percent |
| 101 | +of the AllocationClass is free. If percentage of free AllocationClasses is between `maxAcAllocationWatermark` |
| 102 | +and `minAcAllocationWatermark`: then extra checks (described below) are performed to decide where to put the element. |
| 103 | + |
| 104 | +By default, allocation will always be performed from the upper tier. |
| 105 | + |
| 106 | +- `acTopTierEvictionWatermark`: If there is less that this percent of free memory in topmost tier, cachelib will attempt to evict from top tier. This option takes precedence before allocationWatermarks. |
| 107 | + |
| 108 | +### Extra policies (used only when percentage of free AllocationClasses is between `maxAcAllocationWatermark` |
| 109 | +and `minAcAllocationWatermark`) |
| 110 | +- `sizeThresholdPolicy`: If item is smaller than this value, always allocate it in upper tier. |
| 111 | +- `defaultTierChancePercentage`: Change (0-100%) of allocating item in top tier |
| 112 | + |
| 113 | +## MMContainer options |
| 114 | + |
| 115 | +- `lruInsertionPointSpec`: Can be set per tier when LRU2Q is used. Determines where new items are |
| 116 | +inserted. 0 = insert to hot queue, 1 = insert to warm queue, 2 = insert to cold queue |
| 117 | +- `markUsefulChance`: Per-tier, determines chance of moving item to the head of LRU on access |
0 commit comments