mirror of
https://github.com/mailscope/kumomta.git
synced 2026-09-05 18:18:56 +00:00
Wez Furlong
379d8aebbd
Two issues here: 1. The maintainer would repeatedly try to shrink the ready queue each time it woke up during a low memory condition. This has been fixed to trigger whenever we transition to low memory instead. 2. At some point during refactoring, we dropped the save part of the message shrinking processing, so we'd only successfully shrink messages that had previously been saved and stored to spool. Messages that we deferred spooling, or otherwise modified post reception, would not be saved and thus not be eligible to shrink. Ideally we'd have an integration test for this, but it is a bit awkward because we'd need to contrive an appropriate ulimit for just this instance and generate appropriate load to trip over that limit. I don't fancy the chances that such a test wouldn't be flakey. My ad-hoc test procedure was: ulimit -m 2028527 ./target/release/kumod --policy simple_policy.lua then in another window: ./target/release/traffic-gen --target 127.0.0.1:2025 --body-size 100000 --duration 3600 --throttle 15000/s --http the generator will eventially experience load shedding http responses, and you can see the shrink procedure triggering in the kumod output. curl -s 'http://127.0.0.1:8000/metrics' | grep memory can also be used to check the usage, limit and how many times it trips. You can also use smtp for this, but the smtp client in traffic gen will try hard to reconnect without telling you about the shortage, so you will need to look at the metrics to see it happening.