Uwe,
I'm running and old version of courier-imap-1.7.2p0 mostly with POP3
accounts, some imap too.
This patch i found on the courier-imap mailing list some years ago
helped me reduce the average
load of the machine, and was able to accept more accounts. I don't know
if it might be helpfull to you.
Also add imapproxy, that will reduce some load too.
Anyway, i'm having big load again due to much more accounts being added.
Currently it's holding
over 7000 email accounts on a pentium4 2.80ghz. The average load reaches
tops of 50 , and
is usually at 15 to 20. At night it comes down to a load average of 2.
The load average is mostly to disk usage, so i'm planning on upgrading
this to OpenBSD 4.3 as
soon as possible, and run the newest courier-imap software. Once there i
will split accounts on
two servers using Perdition or the courier-imap built-in proxy
aggregator. I will do this as soon i
get new hardware, i'm looking for a 1U IBM Server which i'd like to use
for this purpose.
Does anyone has experience with Perdition and/or the built-in proxy
aggregator? Which
one has best performance?
And, different subject , what 1U IBM Servers are supported by OpenBSD? I
had never had
the chance to get one to test. Reccomendations?
Oh yes, here's the patch i mentioned you
------begin-cut----
--- pop3dserver.c Mon Apr 28 15:40:19 2003
+++ /usr/ports/mail/courier-imap/pop3dserver.c Tue Jul 3 16:13:31 2007
@@ -314,6 +314,10 @@
struct msglist **prev_list;
int savesizes=0;
+// PATCH: dont scan every file, ignore rfc like qmail-pop3d
+char *p;
+long s;
+
if (msglist_cnt == 0) return;
if ((msglist_a=(struct msglist **)malloc(
@@ -349,6 +353,13 @@
}
else
{
+
+ // PATCH: dont scan every file, ignore rfc like qmail-pop3d
+ // msglist_a[i]->filename =~
1018021353.83146_0.host.dom,S=9249:2,S
+ if( (p=strstr(msglist_a[i]->filename,",S=")) &&
(s=atol(p+3))>0 )
+ msglist_a[i]->size = (off_t)s;
+ else // fallback to slow rfc-conformant scan
+
calcsize(msglist_a[i]);
savesizes=1;
}
------end-----cut--
Uwe Dippel escribió:
Stuart Henderson wrote:
You can restrict sessions per IP very easily with PF.
Yes, Stuart,
and no. It is never good engineering practice to turn two knobs at the
same time. Firstly, when opening a new folder, courier-imap honours
its limitation gracefully. Second, it would limit the communication
channel between daemon and client. An innocuous 'go to another folder'
or even 'stop search' (agree, it doesn't work as of now, but it
should!) would be dropped. It would still not deliver search results,
because it would spawn N identical searches (N defined by pf). I could
try, and I would as well have to look into it myself, because I don't
know how long the timed-out earlier requests would still count as
'link', since the client seems to consider them dead after
Thunderbirds 60-second mailnews.timeout.
Now, thinking of it, if you don't mind following the line of
arguments: even worse:
- the links are considered 'timed-out', then pf doesn't limit the
number of searches
- the links are considered 'active by pf, then any request by the
client of moving away and going to another folder is dropped
Couldn't be worse, could it!?
What bugs me as well: I have been discussing the matter on the
courier-imap list, but nobody answered, and the upstream writer never
wrote anything but that line of 'courier-imap does not fork'. Over the
years, I have entrusted by IMAP-clients to courier-imap thinking it
was well-written. I start to have my doubts.
Can anyone with dovecot on a very tiny box confirm or deny that it
acts differently? One needs to have more mails in a box than the
daemon can search within the 60 seconds time-out. Then, in the status
bar of Thunderbird, it will say something like 'Connecting to
imap.example.com ...' once per minute. Let it go for some minutes, and
then observe the resource usage on the server.
If dovecot is fine, I'll change immediately. :)
Uwe
