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

diff --git a/pbs-tools/src/lib.rs b/pbs-tools/src/lib.rs
index c9d95dd9..939ba7e6 100644
--- a/pbs-tools/src/lib.rs
+++ b/pbs-tools/src/lib.rs
@@ -1,18 +1,29 @@
-pub mod auth;
-pub mod borrow;
-pub mod broadcast_future;
 pub mod cert;
+pub mod crypt_config;
 pub mod format;
-pub mod fs;
 pub mod json;
+pub mod lru_cache;
 pub mod nom;
-pub mod percent_encoding;
-pub mod process_locker;
 pub mod sha;
-pub mod str;
-pub mod sync;
 pub mod ticket;
-pub mod tokio;
 
-mod command;
-pub use command::{command_output, command_output_as_string, run_command};
+pub mod async_lru_cache;
+
+/// 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);
+    }
+}