Following are some practices that have been observed to improve the performance and stability of the GroupWise MTA. They are not hard-and-fast rules, however, and anything published by Novell should likely take precedence. System DesignKeep in mind that you can have an MTA only where you have a domain. This means that if your system has some natural transfer points (such as on the segment with an edge-router, or at the firewall), you might want to consider putting a domain there so that there will be an MTA at that point. Assume that you will be building a large system and will be using occasional indirect connections. Here are a couple of rules of thumb:
Remember, even though MTAs can communicate directly with any other MTA with a valid IP address, this is not always the best way to connect, especially where there are many router hops between them. Because packets are going to be stored and forwarded on these long routes, you should consider having the MTA store and forward the messages (by using indirect connections). This way you will be less likely to have problems with TCP connection timeouts, and your message transfers will be more efficient. TCP/IP Versus UNC LinksTCP/IP links between MTAs or between the MTA and the POA are always preferred. This is true even when the MTA and the POA are on the same server. Here's why: When a link between the MTA and the POA is UNC, messages are queued, and then discovered via a polling cycle. The queuing and polling process causes messages to flow at a slower rate than when messages are sent via TCP/IP. The Linux MTA will support only TCP/IP links. Moving MTAs to New IP Addresses or PortsFirst of all, if you are moving an MTA to a new IP address, it is probably because you are moving the entire domain directory to a new server. If that is the case, review Chapter 20, "Troubleshooting Message Flow," for the complete procedure. Perhaps, though, all you are doing is moving the file server to a new LAN segment and assigning it a new IP address. Here is the procedure you should follow:
These are just a few simple steps, but they are essential for connectivity. Tuning the MTATypically, a busy MTA needs little tuning to keep up with its queues. If TCP/IP links are used exclusively, the MTA will not need to waste CPU cycles polling or maintaining idle connections and will have the resources it needs. You might find, however, that some types of messages need to be moved faster than others. Remote users and users making busy searches both use the high-priority queues. To weigh these queues a little more heavily, check the Use 2nd High Priority Router box found on the Agent Settings tab of the MTA detail window. This will spawn an additional thread for the 0 and 1 subdirectories. The more connections the MTA services, the more threads will be spawned. If the server is having trouble keeping up with queues, this will mean that the mail priority queues (27) will back up even further, whereas the 0 and 1 are processed more quickly. On large systems, an MTA on a Pentium IIclass server should be able to process at least 100,000 messages each day without noticeable backups in any of the queues. Some administrators have seen MTAs that process three times that many messages in a day. |