Re: [Dovecot] many instances om imap and imap-login
On Tuesday 26 April 2005 15:19, you wrote:
Thanks for extensive answer.
I will look into all your suggestions.
Please keep the mailing list in the response, it allows other people to provide advice, follow the conversation, and you get, hopefully, complete solutions stored in the archives waiting for Google to index.
Answers to you questions:
Are the mailboxes being accessed via Webmail?: yes they can but arent at the moment (squirrelmail)
Webmail can cause lots of extra connections to me made.
What Mail application are your users using?: Thunderbird 1.0.2
Don't have much experience with this client, although it works when I've tried it. Others may be able to provide experience here.
Have you checked what state the connections are in?: Do you mean of they are connected or not? when I run top I do see instances called IMAP owned by each user so I asume they are connected
mail# netstat -f inet -p tcp | grep imap tcp4 0 0 mailserver.imap client01.1386 ESTABLISHED tcp4 0 0 mailserver.imap client02.1344 ESTABLISHED tcp4 0 0 mailserver.imap client01.1108 ESTABLISHED tcp4 0 0 mailserver.imap client03.54607 ESTABLISHED
mail# netstat -a -f inet -p tcp | grep "*.imap*" tcp4 0 0 *.imaps *.* LISTEN tcp4 0 0 *.imap *.* LISTEN
FreeBSD 5.4 with a few Outlook and KMail clients.
/jon
Dominic Marks said the following on 2005-04-26 16:11:
On Tuesday 26 April 2005 14:58, Jon wrote:
Hi,
Im using dovecote as my IMAP interface. However i do have a lot of imap instances. its only 7 user using the system as i get this. please advice.
Having lots of processes running isn't automatically a bad thing, but you do
seem to have quite a lot of imap and imap-login processes, so:
From a dovecot.conf on a server I run being used by about 7 people:
(Comments are from dovecot-sample.conf)
# Should each login be processed in it's own process (yes), or should one # login process be allowed to process multiple connections (no)? Yes is more # secure, espcially with SSL/TLS enabled. No is faster since there's no need # to create processes all the time. login_process_per_connection = no
So if security is less of a concern than having many processes running, you should set this to no.
# Number of login processes to create. If login_process_per_user is # yes, this is the number of extra processes waiting for users to log in. login_processes_count = 1
I set this low because I don't need the extra processes.
# Maximum number of extra login processes to create. The extra process count # usually stays at login_processes_count, but when multiple users start # logging in at the same time more extra processes are created. To prevent # fork-bombing we check only once in a second if new processes should be # created - if all of them are used at the time, we double their amount until # limit set by this setting is reached. This setting is used only if # login_process_per_use is yes. #login_max_processes_count = 128
You might want to set this to something like 4?
# Maximum number of connections allowed in login state. When this limit is # reached, the oldest connections are dropped. If login_process_per_user # is no, this is a per-process value, so the absolute maximum number of users # logging in actually login_processes_count * max_logging_users. #login_max_logging_users = 256
Probably no need to worry about this.
1230 ? S 0:00 imap-login 1309 ? S 0:00 imap-login
<snip>
2387 ? S 0:00 imap-login 3095 ? S 0:00 imap 3096 ? S 0:00 imap-login
/jon
Other things to think about:
Are the mailboxes being accessed via Webmail? What Mail application are your users using? Have you checked what state the connections are in?
HTH,
-- Dominic GoodforBusiness.co.uk I.T. Services for SMEs in the UK.
participants (1)
-
Dominic Marks