Hi
I have applied this patch to the 1.6.2 and the load-average is now OK.I totaly agree with you. Beening RFC compliant litteraly explode ressources of host hosting pop3 server. We had load about 300 on Netra T1 using NFS because of that.
Thanks for your help.
Now, i don't understand why this is not the default method.
To be RFC Compliant is ok, to be efficient is better i think.
Because having a problem with 100 connection with a dual processor server and two network filer F760 as storage system is not acceptable.
Last CVS snapshot of courier-imap introduces a cache system.... but in a file... This is also a strange idea, let me explain what.
On a local filesystem you are allmost sure that locks (kernel locks) are ok.. but on a distant filesystem like NFS is locks are not sure. In fact in a Netapp we found there is a limit.
Writting the cache a in file on a maildir can give some races on a complex cases. Imagine you have a pop3 account shared with 3 users and have 3 pop3 server (with data on NFS) behind a lot balancer. How can all pop3 servers knows that current pop3 cache file is being modified.
Olvier Girondel has wrote a patch that add a ,P=<popsize> in filename... the same way as in ,S=<mailsize> why do we not use that on mainstream courier-imap.
No. Just be sure your rsize and wsize on your NFS mount is 8192... Because buffers are kindly hardcoded in source code which is baaaaad... ;/Do you know if there is the same problem with imap server ?
/Xavier
thk a lotbest regards Roland Schneider wrote:--J�r�me Bolliet wrote on 08.01.2003 13:20 +0100: [...]If i'm compare two SGI, one running Qmail POP3D and the other running Couriercourierpop3d scans every single line on every login to compute
POP3D 1.6.1, each in production with 100-110 connection each, i have :
Qmail POP3D :
IRIX64 vercors 6.5 IP27 load averages: 0.86 1.13 1.19 13:13:43
98 processes: 97 sleeping, 1 running
2 CPUs: 58.9% idle, 16.3% usr, 23.9% ker, 0.0% wait, 0.0% xbrk, 1.0% intr
Memory: 1152M max, 878M avail, 733M free, 1024M swap, 1024M free swap
Courier POP3D :
IRIX64 maupassant 6.5 IP27 load averages: 55.41 59.31 70.62
13:05:57 149 processes: 146 sleeping, 1 zombie, 2 running
2 CPUs: 0.0% idle, 23.8% usr, 45.8% ker, 22.8% wait, 0.0% xbrk, 7.6% intr
Memory: 1280M max, 877M avail, 706M free, 1024M swap, 1024M free swap
the size with crlf as required/recommended by rfc.
I had a mailbox with ~2500 messages on a crypto-fs which took
more than 12 cpu-seconds at each poll on a P200.
100 concurrent users scanning their pop3 continously explain
the load of 55, only a faster raid would help somewhat.
qmail-pop3d simply returns the filesize from a stat, the only
problem I know was with fetchmail about 2..3 years ago.
If you deliver with courier (or maildrop or deliverquota) the
size of the file will be embedded into the filename, and allows
very fast operation, even faster than qmail and polling the
mailbox with the 2500 messages above takes less than one second.
The patch below is quite simple, and expects to find ',S=nnn' in
the filename or will fall back to the traditional method.
You also could add a stat there.
+++ imap/pop3dserver.c
@@ -113,6 +113,9 @@
DIR *dirp;
struct dirent *de;
struct msglist *m;
+// PATCH: dont scan every file, ignore rfc like qmail-pop3d
+char *p;
+long s;
if ((dirp=opendir("cur")) == 0)
{
@@ -140,7 +143,13 @@
m->next=msglist_l;
msglist_l=m;
msglist_cnt++;
- calcsize(m);
+
+ // PATCH: dont scan every file, ignore rfc like qmail-pop3d
+ // de->d_name =~ 1018021353.83146_0.host.dom,S=9249:2,S
+ if( (p=strstr(de->d_name,",S=")) && (s=atol(p+3))>0 )
+ m->size = (off_t)s;
+ else // fallback to slow rfc-conformant scan
+ calcsize(m);
}
closedir(dirp);
}
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld =omething 2 See!
http://www.vasoftware.com
_______________________________________________
courier-users mailing list
[EMAIL PROTECTED]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
-- (o_.' J�r�me Bolliet - DRS/Dpt Ing�nierie Internet //\ Noos - 20, place des vins de france 75614 Paris Cedex 12 V_/_ T�l.: 01.44.87.52.84 Email: [EMAIL PROTECTED] (s'il n'y a pas de solution, c'est qui n'y avait pas de probl�me...) ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
