On Wed, 2007-06-13 at 14:16 +0200, Thomas Hummel wrote: > On Wed, Jun 13, 2007 at 02:43:47PM +0300, Timo Sirainen wrote: > > Thanks for your answer. > > > it creates a new connection to auth-worker socket. > > all the workers and the auth process communicate through a single unix > socket, doesn't they ?
There'a a unix socket listener for each auth master process (so with count=2 there are two sockets). > > Auth workers are used only with MySQL auth, or if you're using > > blocking=yes with passwd or PAM. > > Why ? what is basically the idea behind that ? The worker processes are used for passdbs and userdbs that do blocking lookups, so that it doesn't block the whole dovecot-auth while waiting. Other passdbs and userdbs use non-blocking lookups so doing those lookups in worker processes just adds extra overhead. > > With others everything is done in the main dovecot-auth process. > > Ok, so that's my case. So I can safely set auth_worker_max_count to 0, > right ? Doesn't matter, because the setting isn't used if you don't have any worker processes anyway. > > Creating a second auth block is pretty pointless. It creates a new auth > > socket and then login processes connect to both of them and somewhat > > randomly pick either one of them to authenticate against. > > But in that case, another dovecot-auth process get created as well, > doesn't if ? So why isn't the load balanced ? But login process still connects to both of them, and you'll get twice as many connection refused errors. > > You could also use login_process_per_connection=no so it would use > > persistent imap-login processes without having to reconnect to > > dovecot-auth all the time. http://wiki.dovecot.org/LoginProcess > > Yes, I tried that. And doesn't help? You shouldn't get any connection refused errors with login_process_per_connection=no because there are only a few long running login processes that never reconnect to dovecot-auth. If you really do get such errors, it means that dovecot-auth is crashing or something (and the logs should say if it does). > Should I try something with the 'auth_cache_size' parameter as well ? > What would be a reasonable value if its relevant ? No idea. Maybe a megabyte. You can get cache hit/miss statistics by sending USR2 signal to dovecot-auth. What passdb and userdb are you using?
signature.asc
Description: This is a digitally signed message part
