Chapter 10 Monitoring and Maintaining Your Server

After you install and configure Netscape Messaging Server, you need to perform various tasks to monitor and maintain your server. Many of these tasks are performed automatically by the server. For example, the stored utility performs daily maintenance tasks for the server, such as erasing messages stored on disk according to expiration policies you specify. This chapter contains the following sections:

• Overview
• Performing Daily Tasks


• Starting and Stopping Services


• Monitoring and Controlling Disk Usage


• Monitoring Server Response Time


• Performing Recovery Tasks


• Factors Affecting Messaging Server Performance


• System Monitoring Tools


• Using SNMP on Unix Platforms


• Interface Reference: SNMP Configuration

• Monitoring disk usage
• Monitoring server performance and response times


• Managing exception conditions when and if they occur


• Reconfiguring, when necessary, to accommodate new users or new conditions

• CPU performance
• Disk I/O


• Memory usage


• Network performance

Messaging Server has a predefined administrative mailing list set up for postmaster email. Any users who are part of this mailing list will automatically receive mail addressed to postmaster.

Netscape Messaging Server creates a separate set of log files for each of the major protocols, or services, it supports: SMTP, IMAP, POP, and HTTP. You should monitor the log files on a routine basis--especially if you are having problems with the server. For information about searching and viewing log files, see Searching and Viewing Logs.

The stored utility performs automatic monitoring and maintenance tasks for the server, such as:

• Background and daily messaging tasks
• Deadlock detection and rollback of deadlocked database transactions


• Cleanup of temporary files on startup


• Implementation of aging policies


• Periodic monitoring of server state, disk space, service response times, and so on


• Issuing of alarms if necessary

configutil -o alarm.disavail.msgalarmstatinterval -v 600

configutil -o alarm.diskavail.msgalarmthreshold -v 20

You can control disk usage by setting user disk quotas, specifying aging policies for messages stored on disk, limiting the size of messages the server will accept, and processing the message queue at frequent intervals. If these methods are not sufficient or are not acceptable to your users (or are not practical), you might want to consider adding disks to your system. For more information, see Specifying Alternate Paths for Physical Queues and Configuring Message Store Partitions.

If disk space is limited, you might want to set user disk quotas for your system. Disk quotas allow you to limit users to a fixed mailbox size. If a user exceeds the limit, the user can no longer retrieve mail until he or she deletes existing messages to free disk space. For information about specifying message quotas, see Configuring User Disk Quotas.

Another method for controlling disk space is to specify aging policies for messages in the message store. You can control how long messages are stored in one or more mailboxes. If you set aging policies, you should educate your users about these policies because the server will not send a warning message before it starts deleting messages from the store.

• Number of messages in the mailbox
• Total size of the mailbox


• Number of days that messages remain in the mailbox


• Number of days that messages exceeding a given size remain in the mailbox

You might want to limit the size of messages that your server will accept. If you limit message size, the server will automatically reject any messages that exceed the maximum message size. By limiting the size of messages, you'll save queue disk space and message store disk space. For more information about how to limit message size, see Limiting Message Size (SIZE).

You can specify a minimum amount of disk space that will remain unused for the message queue. If the minimum threshold is reached, the server will temporarily reject all messages until disk space is freed. The server returns an error (452) notifying the client of a temporary disk space shortage and asking the client to resend the message at a later time. For information about how to reserve free disk space, see Reserving Free Disk Space for the Message Queue.

You must ensure that you have adequate disk space for the session cache. If you are running out of disk space when starting server processes, check your temporary directory (by default, this directory is located at msg-instance/tmp). By default, for each entry in an SSL server session cache file, 512 bytes are allocated on disk. To ensure adequate disk space, you should allocate 512 bytes per session ID.

configutil -o service.imap.sslcachesize -v number

configutil -o local.tempdir -v path

• Run stored at off hours--not during peak hours for your business.
• Defer queue processing to off hours.


• Reduce the size of the queue.


• Distribute the queue across multiple physical disks.


• Distribute the message store across multiple physical disks.


• Limit the size of user inboxes.

• Number of Users per Disk
• Configuration of POP, IMAP, and HTTP Services


• Configuration of SMTP Services


• Configuration of Logging Services


• Size of Mailboxes


• Distribution of the Store and Queue Directories


• MTA Thread Settings


• Applications Co-Resident with Messaging Server


• Activity of Administration Server


• Activity of Directory Server


• Location of Messaging Server and Directory Server


• Number of Address Lookups per Message


• Ratio of Local Delivery to Outbound Sends


• Use of RAID Technology


• Memory, Disk, and CPU Requirements

As the number of users per disk increases, the I/O to that disk increases non-linearly due to the algorithms used by the OS to cache the directory index (it's faster to search memory than to search a hard drive). To improve disk access, you should distribute users across available disks.

How you configure your POP, IMAP, and HTTP services affects Messaging Server performance. You can configure the following:

• The number of POP, IMAP, and HTTP processes
• The number of POP, IMAP, and HTTP connections per process


• The number of threads per POP, IMAP, and HTTP process

This section summarizes SMTP configuration options that affect system performance. Some of these options can improve server performance; other options provide valuable features but can impact server performance adversely. If you are having problems with server performance for whatever reasons, you might want to consider whether you need the features provided by some of these options. SMTP configuration options that can affect server performance include:

• Limiting Dial-up Connections
• Limiting the Size of Messages


• Verifying Recipient Addresses


• Performing Reverse IP Address Lookups


• Specifying Alternate Search Methods


• Specifying "From" Address Rewrite Style


• Using the Plug-in API

You can improve server performance by limiting the number of dial-up connections to your server. If both client (in this case another MTA) and server support the ETRN command, when the client connects to the server to send a message, it can also initiate processing of the deferred queue for the client's domain. This feature is useful for sites that are set up as secondary mail exchange (MX) hosts for other sites that only have a dial-up connection to the Internet. By enabling this command, you permit dial-up servers to request delivery of their mail. For more information, see Enabling Requests for Deferred Queue Processing (ETRN).

The size of messages is a factor when considering the transmit time to actually "move" the message from the client to the server and the disk space available for storing messages. Users may negatively impact performance by sending extremely large documents over the network. You can limit the size of messages your server will accept. For more information, see Limiting Message Size (SIZE).

You can specify an option to verify recipient addresses when a client connects to the server. Specifying this option has slight performance impact because the server must perform an LDAP lookup for each recipient while connected to the client. The benefit is that the server can detect bad recipient names in the envelope address and return an error to the client before the client sends the body of the message. The client can fix the address before sending the message text. For more information, see Verifying Recipient Addresses.

If you enable this option, Messaging Server will use DNS to map the client's IP address to the associated host name. The host name is then used in the process table, the log files, and in "Received" lines in message headers. This option requires DNS lookups, however, so enabling this option can impact performance adversely if your server handles a large volume of messages. For more information, see Performing Reverse IP Address Lookups.

If you enable alternate search methods, you can expand the list of possible recipient matches. Be aware that enabling this option can impact server performance because of the increase in LDAP lookups. For more information, see Specifying Alternate Search Methods.

Rewriting the "From:" address increases the odds that replies to outgoing messages are processed correctly. However, this feature does incur some performance overhead. For more information on this option, see Specifying From Address Rewrite Style.

If you are using the Messaging Server plug-in API, some CPU and memory resources will necessarily be diverted from the usual Messaging Server processing. However, you can use the plug-in API to provide valuable extensions to the Messaging Server capabilities. For more information, see Chapter 7, Working with SMTP Plug-Ins.

Logging options can be expensive in terms of server performance and response time. You should carefully consider your logging requirements and log only those messages that you need to successfully monitor and maintain your server. For more information on logging policies, see Defining and Setting Logging Options.

Users with mailboxes that contain an extremely large number of messages might encounter slow response times from the server. If so, you might want to set up user disk quotas or aging policies for user mailboxes. For more information about disk quotas and aging policies, see Chapter 5, Managing the Message Store.

The store directory contains the user mailboxes. The queue directory is a temporary directory where all mail manipulation and rewriting take place. To improve disk access, the store directory and the queue directory should reside on separate disks. If you have a fast RAID setup (see Use of RAID Technology), you should keep the store and the queue on separate disks. You should also consider:

• Mounting the Queue Directory on a Fast File System and Fast Disk
• Distributing the Queue Across Disks


• Distributing the Store Across Disks

Because the message queue directory is the most heavily used part of the system, you should mount the queue directory on a very fast file system, such as the Veritas file system (VxFS). Mounting the queue directory on a fast file system can significantly increase performance for SMTP accept rates. By maintaining the queue directory in its own file system, you can also monitor message queue performance separately from message store performance.

If you have more than one disk available, you might want to distribute the queue across disks. By distributing the queue, you can reduce the load associated with delivering a message because the server can perform concurrent I/O operations. You can also use multiple queue directories to reduce the overhead associated with large number of files accumulating in a single queue. For more information about specifying alternate queues, see Specifying Alternate Paths for Physical Queues.

For improved mailbox access performance, you can distribute the message store across multiple disks. When distributing the message store, you should limit the number of mailboxes on any one disk.

• Disk capacity
• Disk space allocated to each user

You can use the configutil utility to modify the thread settings for various MTA components:

  service.smtp.account-handler.minruncount
  service.smtp.autoreply-handler.minruncount
  service.smtp.error-handler.minruncount
  service.smtp.mailbox-deliver.minruncount
  service.smtp.prog-deliver.minruncount
  service.smtp.smtp-accept.minruncount
  service.smtp.smtp-deliver.minruncount
  service.smtp.smtp-router.minruncount
  service.smtp.unix-deliver.minruncount

configutil -o service.smtp.smtp-accept.minruncount -v 75

configutil -o service.smtp.mailbox-deliver.minruncount -v 5

Be aware that other applications running on the same system as Netscape Messaging Server will compete for the same system resources (memory, disk space, and so on) as Messaging Server. Depending on your messaging requirements, you might want to dedicate one or more machines to the messaging services.

If Netscape Administration Server is being used while Netscape Messaging Server is running, there will be less memory available for general use.

If Messaging Server is competing with numerous other LDAP clients (for example, other Netscape servers or a synchronization process with another LDAP based directory) for access to Directory Server, Messaging Server performance will be affected. Under large stress loads, you should replicate the directory services to more machines to increase accessibility of the service. You should also dedicate a directory machine to one or more Messaging Servers.

In general, for improved performance, you should keep Messaging Server and Directory Server on separate machines. Placing these servers on separate machines will prevent contention over system resources (CPU, RAM, and disk space).

Be aware that if the average message is destined for a large number of recipients, there is a corresponding increase in the number of required LDAP lookups required to resolve the address. You might want to limit access to aliases that contain a large number of users; for example, you might not want all users to have access to the companyall alias.

Most customers have a higher number of messages received to messages sent per user (on the order of 4 to 1 or higher). Netscape messaging solutions are optimized for exactly these kind of environments. Because sending a message on the server is more "expensive" than receiving, any deviation from the expected ratio (for example, 1:1 sending and receiving) will affect the expected performance and scalability of your Messaging Server.

To ease management of multiple disks, you can use RAID (Redundant Array of Inexpensive Disks) technology to distribute data across a series of physical disks. With RAID technology, multiple disks appear as one logical volume, so disk management is simplified. You can have multiple logical volumes each consisting of several physical disks.

As stated before, a well-configured server cannot perform well on a poorly-tuned system. During the initial planning stage, you need to estimate your memory, disk, CPU, and network bandwidth requirements for your business environment. These estimates depend on many factors, including how many users the server supports, average number of messages per user, geographic location of users, and so on.

• The master agent handles all communication between servers, through their subagents, and the network management station. The master agent is installed with the Administration Server, and is controlled through its user interface. For more information, see Managing Servers with Netscape Console.
• The subagent for each server has access to its operation information, which the subagent sends to the master agent when requested. The Messaging Server subagent is installed with Messaging Server and is controlled by the SMTP Settings form. For more information, see The Messaging Server Subagent.

To exchange network information, SNMP uses protocol data units (PDUs), which contain information about the variables stored on the server. The network management station (NMS) and the server, or managed device, exchange PDUs in either of two ways:

• In network management station-initiated communication, the management station queries the server for data. This accounts for most communication between the management station and a server. Messaging Server 4.1 supports querying server data only.

In a network management station-initiated session, the management station identifies which servers and variables to monitor by examining the MIB. Then, the management station sends a PDU to the master agent, which passes it to the subagent of the server. The subagent returns the data to the master agent, which sends it back in PDU form to the management station.

• In managed-device-initiated communication, SNMP uses traps to send information about network events, such as shutdown and startup.

In a managed-device-initiated session, when a monitored event occurs, the subagent sends a trap to the master agent, which forwards it to the network management station. For information about traps, see MIB Traps.

The Messaging Server's SNMP subagent, called ns-mailagt, gathers data about Messaging Server's activities. You can configure some parts of the subagent through Netscape Console.

• It reads its configuration information, which is stored in the Directory Server. This is the information you can set by using Netscape Console.
• It initializes the Messaging Server MIB, which contains variables that store network information.
• It informs the master agent about the part of the MIB subtree that it monitors, and therefore what information it can provide. In this case, the Messaging Server subagent monitors, and can provide, only Messaging Server MIB data.

You use the Messaging Server SNMP tab, which is part of Netscape Console, to set some options for the subagent, enable server statistics collection, and start or stop the subagent. After you modify the subagent, you must restart it before your changes can take effect.

1. In the Messaging Server Console, select the server for which you are setting subagent options.
2. Under Server Group, double-click the Configuration tab.
3. In the window on the right side of the page, click the SNMP tab.

• Configuring the Subagent
• Starting and Stopping the Subagent

To configure the SNMP subagent on your system and enable statistics reporting to the network management station, you use the SNMP tab, which is part of Netscape Console.

1. Go to the SNMP tab. For directions, see Configuring SNMP.
2. At the top of the SNMP Settings form, configure the fields as follows:

Master agent hostname. In this field, enter the name of the host where the SNMP master agent resides. This must be a machine name, not an IP address. Default: localhost.

Master agent port number. In his field, specify the port number the subagent uses to communicate with the master agent. Default: 199.

Organization name. In this field, enter the name of the organization using Messaging Server. Usually this is a department or company name.

Server Description. In this field, enter a text description that uniquely describes this Messaging Server installation, for example, the Messaging Server for Marketing.

Contact person info. In this field, specify the person to contact about anything related to Messaging Server. Usually this is the server administrator. You can enter the name or email address of the contact, or both.

Server Location. In this field, specify the location of this installation of Messaging Server. Usually this is a street address.

The information in these fields is stored in Netscape Directory Server for this installation.

3. Click Save.

A message appears reminding you to restart the subagent so that the settings can take effect. Before you can restart the subagent, you must enable statistics collection.

4. Go on to Enabling Statistics Collection.

The subagent does not report SNMP statistics to the network management station unless you enable statistics collection on the SNMP Settings form, which is part of Netscape Console. If statistics collection is not enabled, the subagent cannot be started.

1. Check the Enable Statistics Collection box.

If you remove the check, the subagent cannot be enabled.

2. Restart the subagent by clicking the Start button.

Your configuration information is stored in Directory Server, the subagent starts, and statistics collection begins.

3. If you want to verify your changes to this form, see Verifying SNMP Configuration Changes.

To start, stop, or restart the SNMP subagent, select one of three options at the bottom of the SNMP Settings form.

1. Go to the SNMP tab. For directions, see Configuring SNMP.
2. At the bottom of the form, click one of these buttons:

Start. Messaging Server attempts to start the subagent.

Stop. Messaging Server attempts to stop the subagent, if it is currently running.

Restart. Messaging Server attempts to stop and then restart the subagent.

You can verify the changes you make using the SNMP Settings form by entering a Messaging command in a command window.

1. Open a Unix command window.
2. Go to the Messaging Server bin directory.
3. Enter the Messaging command configutil. For example:
   configutil | more
   
   You see all Messaging Server configuration statistics.
4. Scroll to the statistics whose names start with SNMP and find the settings you can configure using the SNMP Settings form:

SNMP.master port | 199
SNMP.contact
SNMP.description
SNMP.location

• Configuring SNMP
• Configuring the Subagent


• Enabling Statistics Collection


• Starting and Stopping the Subagent

Save. Click this button to save settings you have made in the SNMP tab.