You are right, we are using sha512 and are discussing mass migrating to sha256 if there is no other way to improve performance of the auth service itself. but I'm afraid this will increase productivity by a maximum of two times and the most loaded of the servers will restore the connection pool after a restart not in 20 hours but in 10, which is also unacceptably long.
On Thu, Feb 13, 2025 at 10:23 PM Aki Tuomi <aki.tu...@open-xchange.com> wrote: > I'm guessing the problem is not so much pgsql traffic, than password > veriication. If you are using heavy algorithm like ARGON2 or CRYPT-SHA512 > (e.g.) you need to use a worker to distribute the password hashing effort, > otherwise it'll be all done by the main auth process which can become a > bottleneck. > > Aki > > > On 13/02/2025 16:54 EET Anatoliy Zhestov via dovecot < > dovecot@dovecot.org> wrote: > > > > > > 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 > > _______________________________________________ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
