I hope I know how to use top\htop and so on. ;) And I work with postgres for like 10 years compared to dovecot, which i use less then year.
it's definitely not postgres (and "one core" problem for postgres related with one heavy connect or data modifying, not for "select from") I see only one process that uses CPU100% with a high amount of logins and it's auth. And I see only one 100% loaded core on the server. > What exactly **is** saturating that single core? My guess would be that > it's actually a PostgreSQL process ... ? > > https://dba.stackexchange.com/questions/331757/postgres-using-a-single-proce... > > <https://dba.stackexchange.com/questions/331757/postgres-using-a-single-process-despite-having-64-cores-and-setting-max-worker-p> > https://stackoverflow.com/questions/71416125/postgresql-uses-only-one-core > Kind regards, > Jochen Bern > Systemingenieur > Binect GmbH On Thu, Feb 13, 2025 at 5:10 PM Marc <m...@f1-outsourcing.eu> wrote: > How did you do the test? > > > > > 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
