Set MMAP_THRESHOLD to a fixed value (128K)

[proxmox-backup.git] / pbs-tools / src / lib.rs

diff --git a/pbs-tools/src/lib.rs b/pbs-tools/src/lib.rs
index f36cc17534e3508cedbc2c5b39ec861c57ea655e..939ba7e6b16bba0eb6ea03f31b2bae3e0ebdf4a4 100644 (file)
--- a/pbs-tools/src/lib.rs
+++ b/pbs-tools/src/lib.rs
@@ -1,33 +1,29 @@
-pub mod acl;
-pub mod blocking;
-pub mod broadcast_future;
 pub mod cert;
-pub mod cli;
-pub mod compression;
-pub mod crypt;
 pub mod crypt_config;
 pub mod format;
-pub mod fd;
-pub mod fs;
-pub mod io;
 pub mod json;
-pub mod logrotate;
 pub mod lru_cache;
 pub mod nom;
-pub mod percent_encoding;
-pub mod process_locker;
 pub mod sha;
-pub mod str;
-pub mod stream;
-pub mod sync;
-pub mod sys;
-pub mod task;
 pub mod ticket;
-pub mod tokio;
-pub mod xattr;
-pub mod zip;
 
 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);
+    }
+}