When using DNS names for backends in a proxied setup, the async dns_client
process after a short time of high load (burst scenario) seems to get
overwhelmed:
auth: Debug: conn unix:dns-client: dns(backend.local): Lookup failed after 0
msecs: Failed to connect to dns-client: Resource temporarily
That one truly fixed it, it yields 4500-5000 cycles per second now and the
latency is superb.
In my understanding from the docs this means that before there was only a
single process, doing a single service to the imap-login and then exiting, thus
limiting the login process where now we have at
Thank you for the swift answer. Thats what I tried without success.
service imap-login {
process_limit = 15000
process_min_avail = 48
service_count = 0
vsz_limit = 2 G
}
But I also now tried to set both userdb and passdb to static, to rule out any
caching internals. Performance stood in
For further testing and because I could not figure the limitation, I just
duplicated the dovecot nodes multiple times and loadbalanced over them with
primitive roundrobin TCP.
With every increase of instances I could load the system more and got almost
linear scaling until about 16 instances w
Hello,
I am running a test setup in a docker stack with Dovecot (2.3.21). Basically as
a test to see whats possible.
The whole thing works okay, but I noticed that with imaptest (latest version)
somewhere between 230 and 270 requests per second on a login+logout cycle it
cannot go further. How
Why do you use regex ?
You can just use matches:
https://p5r.uk/blog/2011/sieve-tutorial.html#matchtype
(https://p5r.uk/blog/2011/sieve-tutorial.html#matchtype)
On Wed, Feb 20, 2019 at 03:31 AM, subin ks via dovecot wrote: I've Dovecot and
dovecot-sieve v 2.2.27 installed on a Debian 9.6. I'm
I am trying to add a signature to all messages and it should be possible via
vnd.dovecot.filter, the problem is that any script I try to filter through just
hangs.
I am running on FreeBSD 11.2 and I tried with dovecot 2.2.32 & pigeonhole
0.4.19 and with dovecot 2.3.2 && pigeonhole 0.5.2. In both