Hi Joel,

I think the extra imapd processes you're seeing are the result of a separate 
issue all together.  Most IMAP clients tend to open multiple sessions.  
Usually so they can keep track of new arrivals in INBOX while working on 
different folders.  These aren't forked.  They are separate invocations run 
by ?inetd for new and different network requests.

I remember a few years back dealing with a customer site that used Outlook.  
That version of outlook would open a connection to the mail server for 
_every_ folder the user had recently opened.  Some of the heavier users were 
using 20+ simultaneous imapd processes.

Thanks Microsoft :-;

Jon

On Wednesday 08 November 2006 18:41, Joel Reicher wrote:
> > On Thu, 9 Nov 2006, Joel Reicher wrote:
> > > Is there any data on the extent to which imapd needs to be load
> > > balanced? Is it just because of all the fork()ing?
> >
> > imapd needs little CPU, but intensive I/O and enough memory to prevent
> > swapping.
> >
> > I agree than fork()ing is a problem.  fork()ing can be abolished by:
> >   (1) using Linux or BSD (not using SVR4 or OSF/1)
> > AND
> >   (2) not requiring the use of mlock, one of:
> >       a) deliver mail to a user-owned directory (e.g., the home
> > directory) and not use the spool directory at all
> >      OR
> >       b) protect the spool directory 1777 so .lock files can be created
> >          directly without using mlock.
>
> Interesting. My IMAP server is a NetBSD box, and because I don't have
> many users I use a 1777 spool directory. Moreover, all my users have
> mbx INBOXes in their homedirs so imapd snarfs.
>
> Nevertheless, I still see what looks like one persistent imapd process
> per user (along with others appearing and disappearing when the user does
> particular operations).
>
> So when you say "fork()ing can be abolished" do you mean per user or
> in general? Should I not be seeing these persistent imapds?
>
> Cheers,
>
>       - Joel
> _______________________________________________
> Imap-uw mailing list
> [email protected]
> https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
_______________________________________________
Imap-uw mailing list
[email protected]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw

Reply via email to