X-Git-Url: https://git.proxmox.com/?p=proxmox-backup.git;a=blobdiff_plain;f=pbs-tools%2Fsrc%2Flib.rs;h=939ba7e6b16bba0eb6ea03f31b2bae3e0ebdf4a4;hp=9ea4ea5c940e258b3b5b5011538ebea012bcd119;hb=d91a0f9fc90aecabc4f359d968f716a14562ce78;hpb=9a1b24b6b1089ab8435a38afe4a3de3f99d7628e

diff --git a/pbs-tools/src/lib.rs b/pbs-tools/src/lib.rs
index 9ea4ea5c..939ba7e6 100644
--- a/pbs-tools/src/lib.rs
+++ b/pbs-tools/src/lib.rs
@@ -1,22 +1,29 @@
-pub mod acl;
 pub mod cert;
-pub mod cli;
 pub mod crypt_config;
 pub mod format;
-pub mod fs;
-pub mod io;
 pub mod json;
 pub mod lru_cache;
 pub mod nom;
-pub mod percent_encoding;
 pub mod sha;
-pub mod str;
-pub mod sync;
-pub mod sys;
 pub mod ticket;
-pub mod xattr;
 
 pub mod async_lru_cache;
 
-mod command;
-pub use command::{command_output, command_output_as_string, run_command};
+/// Set MMAP_THRESHOLD to a fixed value (128 KiB)
+///
+/// This avoids the "dynamic" mmap-treshold logic from glibc's malloc, which seems misguided and
+/// effectively avoids using mmap for all allocations smaller than 32 MiB. Which, in combination
+/// with the allocation pattern from our/tokio's complex async machinery, resulted in very large
+/// RSS sizes due to defragmentation and long-living (smaller) allocation on top of the heap
+/// avoiding that the (big) now free'd allocations below couldn't get given back to the OS. This is
+/// not an issue with mmap'd memeory chunks, those can be given back at any time.
+///
+/// Lowering effective MMAP treshold to 128 KiB allows freeing up memory to the OS better and with
+/// lower latency, which reduces the peak *and* average RSS size by an order of magnitude when
+/// running backup jobs. We measured a reduction by a factor of 10-20 in experiments and see much
+/// less erratic behavior in the overall's runtime RSS size.
+pub fn setup_libc_malloc_opts() {
+    unsafe {
+        libc::mallopt(libc::M_MMAP_THRESHOLD, 4096*32);
+    }
+}