]>
Commit | Line | Data |
---|---|---|
4805edc4 | 1 | pub mod cert; |
bbdda58b | 2 | pub mod crypt_config; |
770a36e5 | 3 | pub mod format; |
f75292bd | 4 | pub mod json; |
fc5870be | 5 | pub mod lru_cache; |
18cdf20a | 6 | pub mod nom; |
ba0ccc59 | 7 | pub mod sha; |
9eb78407 | 8 | pub mod ticket; |
e57841c4 | 9 | |
6c221244 | 10 | pub mod async_lru_cache; |
d91a0f9f DM |
11 | |
12 | /// Set MMAP_THRESHOLD to a fixed value (128 KiB) | |
13 | /// | |
14 | /// This avoids the "dynamic" mmap-treshold logic from glibc's malloc, which seems misguided and | |
15 | /// effectively avoids using mmap for all allocations smaller than 32 MiB. Which, in combination | |
16 | /// with the allocation pattern from our/tokio's complex async machinery, resulted in very large | |
17 | /// RSS sizes due to defragmentation and long-living (smaller) allocation on top of the heap | |
18 | /// avoiding that the (big) now free'd allocations below couldn't get given back to the OS. This is | |
19 | /// not an issue with mmap'd memeory chunks, those can be given back at any time. | |
20 | /// | |
21 | /// Lowering effective MMAP treshold to 128 KiB allows freeing up memory to the OS better and with | |
22 | /// lower latency, which reduces the peak *and* average RSS size by an order of magnitude when | |
23 | /// running backup jobs. We measured a reduction by a factor of 10-20 in experiments and see much | |
24 | /// less erratic behavior in the overall's runtime RSS size. | |
25 | pub fn setup_libc_malloc_opts() { | |
26 | unsafe { | |
27 | libc::mallopt(libc::M_MMAP_THRESHOLD, 4096*32); | |
28 | } | |
29 | } |