mirror of
https://github.com/mailscope/kumomta.git
synced 2026-09-10 20:42:14 +00:00
Wez Furlong
722876a144
This commit introduces awareness of memory limits that may have been established for the process. The idea is that the hard/soft limits are read from the active cgroup, falling back to classic ulimit hard/soft limits, falling back to the system RAM size. In the absence of an explicitly configured hard limit, the RAM size is used for the hard limit. In the absence of an explicitly configured soft limit, 75% of the hard limit is used for the soft limit. A background thread monitors the memory usage and (potentially adjusted) memory limits. A low memory state is when the usage is within 10% of the soft limit. In this state, we start to trim back memory usage, shrinking loaded data when messages are placed into the ready queue. A more severe memory state is when the usage exceeds the soft limit. In this state, new message reception is rejected until the usage recovers. kumod doesn't do anything directly with the hard limit, but assumes that the system will terminate the process with no opportunity to safely clean up if that value is reached. In order to reduce the memory usage, the allocator has been switched to jemalloc which has superior management of fragmentation and a control interface to request release of various memory caches. We make use of jemalloc specific functions in the tokio thread pools; when they park (idle), we release the thread local cache, and when we reach the soft limit we aggressively flush the caches until memory usage falls below the limit. There's like some room for tuning of the thresholds around this, but this is a reasonable start. Note that there are no explicit config options in kumod to set the soft and hard limits: those are taken from the process environment and can be simply set either via ulimit in a calling shell script, or via systemd service configuration. We may introduce some knobs for the low memory state threshold in the future.