[Dovecot] Config questionsabout various login parms
I'm currently runing UW-IMAP (compiled vanilla) with procmail and mbox and am making my usual careful crawl (at turtle speed) through figuring out DC config. Some questions: a) I have something like 3-4 root imapd sessions so I presume that the default *login_processes_count* = 3 will be OK. I'm less clear about login_max_processes_count and login_max_connections = 256. A common enough heavy load has something like 275 unique users accessing imap and 600 imapd processes. Suggestions? I'm beginning with no SSL, KISS. b) If I set login_process_per_connection =no, would the number of users accessing imap be the same as the number of imapd sessions? c) login_process_size is confusing/intriguing. If there are 500 processes, the default of 32MB means 16GB (the box has 12GB). OTOH, what about the big players with a 400 MB inbox...will they be able to open their inbox with the default d) login_max_connections ditto...I shouldn't think that an individual user would conceivably have the default of 256, except pathologically....or is this applied to the listening imapd root processes.
Thanks in advance for your help and patience.........
--
Stewart Dean, Unix System Admin, Henderson Computer Resources
Center of Bard College, Annandale-on-Hudson, New York 12504
sdean@bard.edu voice: 845-758-7475, fax: 845-758-7035
On Tue, 2007-03-06 at 16:05 -0500, Stewart Dean wrote:
I'm currently runing UW-IMAP (compiled vanilla) with procmail and mbox and am making my usual careful crawl (at turtle speed) through figuring out DC config. Some questions: a) I have something like 3-4 root imapd sessions so I presume that the default *login_processes_count* = 3 will be OK. I'm less clear about login_max_processes_count and login_max_connections = 256. A common enough heavy load has something like 275 unique users accessing imap and 600 imapd processes. Suggestions? I'm beginning with no SSL, KISS. b) If I set login_process_per_connection =no, would the number of users accessing imap be the same as the number of imapd sessions? c) login_process_size is confusing/intriguing. If there are 500 processes, the default of 32MB means 16GB (the box has 12GB). OTOH, what about the big players with a 400 MB inbox...will they be able to open their inbox with the default d) login_max_connections ditto...I shouldn't think that an individual user would conceivably have the default of 256, except pathologically....or is this applied to the listening imapd root processes.
I think you're misunderstanding all those settings and how the login processes work in general. Also I don't understand what you mean by "root imapd sessions".
The login processes is handling the connection only before user has logged in. After login an imap process is started which does the mailbox opening and such. So login_process_size doesn't affect max. mailbox sizes. mail_process_size however does affect the max. mailbox size, but the default 256MB should be enough to handle hundreds of thousands of mails in a single mailbox. Also both of these specify the maximum allowed virtual process size, they don't really use that much memory to begin with. Their purpose is mostly to just avoid memory leaks from killing the machine.
If you're not using SSL then after user has logged in, the login process knows nothing about the user anymore and it's free to serve another user.
As long as you're not using SSL you could just leave all of them to defaults. Larger login_process_count means however that there are more processes available to handle the user logins, so if a lot of users are logging in at the same time a larger count would perform slightly faster than a lower count.
I guess I should write about this to wiki.
On 7 Mar 2007, at 16:21, Timo Sirainen wrote:
If you're not using SSL then after user has logged in, the login
process knows nothing about the user anymore and it's free to serve another user.
And if you are using SSL? (Which, I'm sure, Stewart will get to in
time)...
If I remember other postings correctly then the login process does
know something about the user: it acts as a proxy, passing data
through from the IMAP client to the imap server process (and
presumably back again?).
Is that right? ... If so, then this was where the "Too many open
files" problem arose in an earlier thread (the stdio library on
Solaris defaulting to only allow 256 descriptors, or something).
Like Stewart, I'm doing the slow turtle-speed crawl and don't have
SSL in place yet. But when I get that far one of the things I have
on my checklist is to verify I can open more than 256 SSL connections
to the server at a time: potentially we'll need 1,000-2,000 at a time
as use of IMAP over SSL increases.
Cheers, Mike B-)
-- The Computing Service, University of York, Heslington, York Yo10 5DD, UK Tel:+44-1904-433811 FAX:+44-1904-433740
- Unsolicited commercial e-mail is NOT welcome at this e-mail address. *
On Wed, 2007-03-07 at 16:56 +0000, Mike Brudenell wrote:
On 7 Mar 2007, at 16:21, Timo Sirainen wrote:
If you're not using SSL then after user has logged in, the login
process knows nothing about the user anymore and it's free to serve another user.And if you are using SSL? (Which, I'm sure, Stewart will get to in
time)...
http://wiki.dovecot.org/LoginProcess
Is that right? ... If so, then this was where the "Too many open
files" problem arose in an earlier thread (the stdio library on
Solaris defaulting to only allow 256 descriptors, or something).
I don't remember anymore what that problem was about. Dovecot itself doesn't use stdio, so it was some library doing it internally. Was it passwd lookup doing that? In that case blocking=yes would help nowadays.
On 7 Mar 2007, at 17:23, Timo Sirainen wrote:
I don't remember anymore what that problem was about. Dovecot itself doesn't use stdio, so it was some library doing it internally. Was it passwd lookup doing that? In that case blocking=yes would help
nowadays.
It was this thread that I'm thinking of: http://dovecot.org/list/dovecot/2007-January/018398.html
I think the eventual conclusion was that it was PAM -> crypt() ->
some sort of hardware crypting device.
My main fear is that I get LDAP working fine without SSL, then turn
it on and find I'm stuffed by only having a maximum of 256 SSL
connections at a time. (If anyone can reassure me this won't be the
case? I'm running under Solaris 10 -- on a SPARC box at present.)
Cheers, Mike B-)
[Aside: I'm a Happy Bunny this afternoon -- I've got Dovecot working
against our LDAP server now ... after applying a liberal dose of
Local LDAP Guru to learn how to use it within our security setup.
I'm planning to write a "How I Did It Without Losing Too Much Hair"
article for the list in due course in case it helps any other newbies.]
-- The Computing Service, University of York, Heslington, York Yo10 5DD, UK Tel:+44-1904-433811 FAX:+44-1904-433740
- Unsolicited commercial e-mail is NOT welcome at this e-mail address. *
On 7.3.2007, at 19.33, Mike Brudenell wrote:
It was this thread that I'm thinking of: http://dovecot.org/list/dovecot/2007-January/018398.html
I think the eventual conclusion was that it was PAM -> crypt() ->
some sort of hardware crypting device.
Oh. That can also be prevented nowadays by using passdb pam { args =
blocking=yes } because then the PAM lookups are done in dovecot-auth
worker processes where login processes don't connect directly.
My main fear is that I get LDAP working fine without SSL, then turn
it on and find I'm stuffed by only having a maximum of 256 SSL
connections at a time. (If anyone can reassure me this won't be
the case? I'm running under Solaris 10 -- on a SPARC box at present.)
If you're using LDAP and something else than CRYPT-passwords then I
don't think there's even a possibility of it breaking with you.
participants (3)
-
Mike Brudenell
-
Stewart Dean
-
Timo Sirainen