I am still having local delivery delay issues. Here is brief description of my system:...
approximately 1100 customers
Intel(R) Pentium(R) 4 CPU 1.60GHz
cpu MHz : 1615.935
hda: 156301488 sectors (80026 MB) w/2048KiB Cache, CHS=9729/255/63, UDMA(100)
[EMAIL PROTECTED] cdick]# cat /proc/meminfo
total: used: free: shared: buffers: cached:
Mem: 924430336 915738624 8691712 0 121597952 469168128
Swap: 534601728 91127808 443473920
MemTotal: 902764 kB
I also support ~1000 users, and use a similar software setup. Our server is a clustered arrangement, one very large NFS back end with 4 small servers doing SMTP/IMAP/POP, etc. The POP3 server is Qmail's pop server with an APOP authentication module, for backward compatibility with our former server's services. Load is somewhat higher because Qmail's pop server does not index messages sizes like Courier's does.
Each of our servers is an 800Mhz P3 mobile with 512MB of RAM and a 20GB IDE drive. Load is very low, delivery is fast. Your system is somewhat shorter of resources than ours... You should probably quantify your load by the number of messages you receive per day rather than by the number of users you support. We get about 224,353 per day.
When you're diagnosing performance problems, try to figure out whether there are specific users having trouble, or if the problem affects the system as a whole. If the problem affects the system, try to figure out what resource is your bottleneck.
You can watch "top" to see CPU utilization, and the processes that are actually using the CPU heavily. If you see PIDs using a lot of CPU for an extended time, you should diagnose them to see why they do that. Very few processes use a lot of CPU time in a mail server.
You can watch 'iostat -x 2' to see which partitions and disks are being used heavily. If a drive's bandwidth is used at max capacity, then you might need to move that partition to a different drive. You would almost certainly benefit from putting /var on a partition of its own.
You can also watch 'vmstat 2'. vmstat can tell you a *lot* if you read it right. Under "procs", you'll see how many processes are waiting for CPU or disk availability in the r and b columns. Under "swap", you can see how heavily your swap partitions are used by watching the blocks swapped in "si" and swapped out "so". If these numbers are high, you should consider adding RAM, or moving swap onto a disk by itself. The "io" columns can tell you how heavily your disk system is being used. If these number are very high, you may need more disks with your partitions spread more evenly across them, or you may just need faster disks (or a combination of both).
One problem that we've seen similar to yours was a user who's maildroprc had many patterns which overused '.*'. When you use '.*', the regex checker can take a very long time to runs its checks. If you have a regex with several '.*' patterns, CPU time used may grow exponentially. This will cause maildrop to time out, and may never succeed, or may succeed only when the system is doing very little else.
I have worked with Sam for a couple of hours and implemented some of his suggestions. The problem still seems to exist and seems to be memory related (ie: when I get into using SWAP, local deliveries slow down).
(Lets see if I get this right) Don't confuse correlation with causality. It could simply be that whatever is causing deliveries to take a long time uses a lot of RAM. That's somewhat different from something using a lot of RAM, and making that resource a bottleneck for everything else.
Especially in the case where your maildroprc, or some user's maildroprc contains patterns with several '.*' wildcards, you may find that maildrop uses a lot of RAM, takes too long to deliver the message, and defers delivery. In that situation, swap is not the cause of your problem. Your maildroprc needs to be fixed.
My question is, should my configuration be able to support 1100 customers effectively? Or are the 24 hour delays expected due to spamassassin having to process each message.
Only you can really find out for sure. It depends on who's sending the system messages.
------------------------------------------------------- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
