its currently 50mb, i will upload it to google drive
thanks! Meanwhile, I pushed this change to reduce the capacity of the memoize cache for shaping data: shaping.lua: reduce memoize cache capacity to 1 · KumoCorp/kumomta@db7d846 · GitHub
Got it, thanks
fyi: updated now to version: kumod 2024.12.10-1c25a0d8
from what i see right now it looks much more better, but its only 5 hours ago. i will update you need days.
@free-spirited-yorksh one instance is now once again at a higher memory limit
if you want, i can enable tracing once again and sent you the report
I have a pending commit that reduces the overhead of tracing; I’d rather wait to get that running and then gather that report
2024-12-12_stats.txt (3.8 MB)
for you 
i know you’re working on your commit, but i wanted to provide something at least
in about 30 minutes from now, please grab a newer build. There’s also a configuration change that I’d like you to apply:
The TSA shaping dump you shared has many entries that apply both our default rule to disable TLS for broken sites, and a rule that I assume is a custom one of yours that matches in similar circumstances to prefer the use of openssl.
I just pushed a commit that replaces our default TSA rule with the use of the newer remember_broken_tls option.
I’d like you to consider removing/disabling the automation rule that is setting TLS to openssl. If you are getting value from the use of openssl and don’t want to lose that, you might consider making it the default for your setup.
Those changes will prevent so many TSA overrides being created in the future, which will reduce the amount of memory that is being reported in the traces for shaping data; that appears to be the most significant usage amongst the rust-tracked allocations.
It will take some time to expire the TSA records and see the effect of this, so you may wish to apply brute force and:
- stop TSA daemon
- remove
/var/spool/kumomta/tsa.db - start TSA daemon
to clear them all out.
I do want to note that we don’t have a complete picture of the usage on your system: upgrading to a newer build will help to understand the difference between the rust-tracked allocations and RSS to see if there might be excessive usage due to either fragmentation or from something that we’re using via FFI that doesn’t use Rust’s allocator (eg: rocksdb, openssl, rdkafka, libunbound or similar)
Thank you for investigation, i will upgrade next day.
i rolled your instructions and have now setup kumo as described. i will update you as soon as i get a memory issue
and just fyi: i double checked generated tsa file - its empty 
FWIW, I had a flash of insight at 3am and I think that shaping.lua: explicit gc in kumo.tsa.config.monitor · KumoCorp/kumomta@b3aa6d4 · GitHub is probably the remedy for the underlying issue. Making those config changes for a smaller TSA setup is still a positive thing, however!
I will update as soon as possible and gonna let u know