(FWIW: I deleted the config tarball message from here on discord because it had a couple of dkim keys inside, and you probably don’t want those to be here)
Thanks.. I was thinking on that.. but that would break the config if not sending them
you could assign messages to the null queue like that; you’ll get Reception records but not any delivery or transfail records, so your logging volume will likely be between 1/2 to 1/3 what you’d see otherwise
And thanks for taking the time to look into this. it is appreciated
Got it… I was not expecting delivery logs indeed
an alternative strategy is to run a second kumomta instance as a sink that discards all mail. Then on your main system under test, you would conditionally set the routing_domain to that sink instance
hmm yes that could work too indeed
alright, time for bed for me (in the netherlands), but I will try to test a bit more in the weekend or earlier (time permitting)
So far so good. Maybe removing that snippet on ‘should_enqueue_log_record’ did the trick. I now have 50% off the email traffic on Kumo and well if it should fails, the sendouts will still be done on Postfix. So I am safe in terms of mail delivery. But I rather have it all on KumoMTA.
I did not change anything yet on the webhook to logstash configuration/performance so I will see if I load KumoMTA for 100% what that brings.
Well I tend to be on the positive… But after increasing the smtp injection load Kumo died again… hanging, no logs, no nothing.
Today I renamed the webhook from webhook2 into webhook. I changed logstash to now use more memory (512Mb instead of 256MB) and I increased the number of threads from 2 to 4. The server is a two core machine so by default logstash uses 2 threads.
I don’t think that those changes will help much, but I want to trickle down what is actually causing this, so I should rule out that logstash is the problem. And if this doesn’t help I will disable the webhook. (But then I loose my easy accessible logging 
).
In the meanwhile I am working on a Zabbix Template to fetch the metrics.json and getting all kinds of metrics. I already have the connection_count. Will work on memory measurement and using delta functionality I will see to keep statistics on total_messages_delivered, total_connection_count, etc.
Maybe that will shed some light in what is happening. In the same time getting data on delivered/bounced mails per time delta is a good thing [tm]. I will update when I know more, don’t think you guys can do much with this info.
Any new insights? We’re working on some improvements for this.
well the improvement on logstash did not help… but I now disabled the webhook.. to see if it will lock up again
so I am a bit blind on the row for row sendouts.. in elastic.. but I can see if it keeps sending stuff
need to wait for a larger sendout.. maybe tommorrow to see if it breaks
@free-spirited-yorksh did anything related get committed yet or is it in diffs still?
Add back-pressure to enqueue during SMTP reception · KumoCorp/kumomta@309ea82 · GitHub may help with this; it is available in currently available dev builds
I can build myself the latest build and see if it works better with the webhook.
maybe I will leave it until tommorrow as it is to see if that was causing the issue… because actually since I upped the sending volume on KumoMTA it locked up pretty quick (sadly)
hmm alright that change looks like too many mails were inserted and then kumo suffocated on it?
before that change, it was possible for the injector to submit more messages on the connection while the previous message(s) were in the process of being placed into the managed queue structure. In the intervening time, the message was implicitly queued into the tokio task queue, which doesn’t participate in memory management of offer back pressure