2.4 docs "The auth workers are used to execute ___blocking___ passdb and userdb queries (e.g., MySQL and PAM). They are automatically created and destroyed as necessary."
postgresql is a non blocking db allowing async queries. But I'll try to check it on the nearest days. On Thu, Feb 13, 2025 at 6:35 PM Aki Tuomi <aki.tu...@open-xchange.com> wrote: > You should be able to use > https://doc.dovecot.org/2.4.0/core/summaries/settings.html#passdb_use_worker > with pgsql too. > > Aki > > On 13/02/2025 15:47 EET Anatoliy Zhestov via dovecot <dovecot@dovecot.org> > wrote: > > > Well, I try, but according to documentation - auth-workers are used for > mysql and not for postgres. > Nothing changes. auth process raises cpu% to 100 and performance not > raised anyway. > > On Thu, Feb 13, 2025 at 5:08 PM Aki Tuomi <aki.tu...@open-xchange.com> > wrote: > > > Try setting > > auth_cache_verify_password_with_worker=yes > > and see if this helps? > > Aki > > On 13/02/2025 14:55 EET Anatoliy Zhestov via dovecot < > > dovecot@dovecot.org> wrote: > > > > > > I set up a test server and started testing it by multiple threads > > (1-200), > > using all the advice given to me. > 1 I disabled the postlogin script > 2 raised maxconns to 200 > 3 set service_count = 400, process_min_avail = 100 > 4 increase auth_cache > 5 increase the pool in postgres > 6 enable high-performance mode for imap-login > > However, the performance of the auth service seems limited by one core > > and > > cannot rise above 30-40 logins per second for our processor (60-70 with > warm cache). > > Still, is there any way to parallelize this? > Having 48 cores to be limited by the performance of the one is too sad. > > > > > On Tue, Feb 4, 2025 at 1:23 PM Timo Sirainen <t...@sirainen.com> wrote: > > On 3. Feb 2025, at 20.18, Anatoliy Zhestov via dovecot < > dovecot@dovecot.org> wrote: > > > >> > >> Are you sure the problem is authentication / pgsql? You could test > > with > > looping "doveadm auth lookup $user" rapidly. Of course for different > > users > >> to avoid them coming from cache. Or if you can reproduce it that > > way, > > try > >> if the same happens for repeating the same user so it does come from > cache. > > > > > > i test in condition when 90% of imap connection is already > > established. > > auth cache is enabled so i guess tests with the same user are not > > relevant. > > > > -------- less loaded server > ps waux|grep imap-login|wc -l > 24977 > > Oh, somehow I missed that you have this many concurrent connections. > > echo "13285 / 343" |bc > 38 (per second) > > So with this speed 24977 users would take 11 minutes to login back, > > which > > is a bit slow. > > Some ideas: > > 1) If pgsql is the bottleneck, try multiple pgsql connections: Add > maxconns=4 (or whatever) to the dovecot-sql.conf.ext's connect line. > > 2) In your Dovecot proxy (assuming you have one?) you can configure it > > to > > spread over disconnections over a long time, if the issue is that > > backend > > disconnects everyone at once. login_proxy_max_disconnect_delay setting > > does > > this. > > 3) With that many connections and to make logins faster, you'd be > > better > > off using > > > https://doc.dovecot.org/2.3/admin_manual/login_processes/#high-performance-mode > > 4) To optimize login performance, it would be best to get rid of the > post-login script. Also: > > service imap { > service_count = 1000 > process_min_avail = 10 > } > > 5) auth_cache_size is rather small. Likely could be increased much > > larger. > > _______________________________________________ > dovecot mailing list -- dovecot@dovecot.org > To unsubscribe send an email to dovecot-le...@dovecot.org > > > > _______________________________________________ > dovecot mailing list -- dovecot@dovecot.org > To unsubscribe send an email to dovecot-le...@dovecot.org > > _______________________________________________ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
