we don't have many pop users but we do have VERY large folders, and I've notced many of them where not
converted to mbx format ;( One user'shad a file that just toped 2 Gigs and was in Unix format !! I'm tring
to put together a csplit regular expression to break it up before converting to mbx as no mail programs
can work with it any more.
Anyway the preformace died again, It seems to happen every 48 hours when the imapd processes get to 250
I was able to run "pkill inetd; pkill imapd " a couple times to kill all imapd's then restart imapd and everything was fine.
I'm also geting console error messages whenever tmail tries to write to new file, the second message always
works and the first one is eventually delievered from que but the errors are annoying.
I'm tempted to go back to the very old imapd 2000 which I know worked, but then I'll never figure out whats wrong.


paul killey wrote:

re: slow performance ... what is killing us is frequent access by pop clients checking to see if they have new e-mail (and they tend to leave e-mail on the server). the imap side of things seems pretty reasonable.

one option we are considering is to place pop users on their own server and letting them choke each other off. i am sure we'll see some educational effort to try and get people to move to imap clients.

we are using solaris ... i'll make sure i have it right and send you (robert) what our ('our' is college of engineering here) config is. the campus-wide imap servers run solaris as well, but have 50M quotas so i don't think they see the large folders. we have 250M quotas.

--paul




Reply via email to