|Netscape Messaging Server
Last update: 2002/05/09
This Tuning Guide has the following sections:
|Platform Tuning Information|
Netscape Messaging Server on Solaris requires the following patches:
Modify the TCP settings (in /etc/system):
hard limit on file descriptors
soft limit on file descriptors
The following effects occur based on your setting of the maxusers parameter:
Bump up the Directory Name Lookup Cache (DNLC):
Bump up the inode cache:
set ufs_ninode=300000 (suggested by Solaris support is 35000)
If you are using Veritas VxFS, check for the following values:
set vxio:vxfs_ninode 400000
For Veritas support you should visit their site: http://support.veritas.com/.
The following should be at the top of /etc/rc2.d/S69inet:
stack tuning for Netscape Messaging
Note: the hiwat settings above will use this much memory per connection, so be aware of the impact on your system.
Also verify that the following parameters are set properly, if needed (in /etc/rc2.d/S69inet):
You should also review whether the Solaris Priority Paging capability is right for you. This is discussed at http://www.sun.com/sun-on-net/performance/priority_paging.html.
Solaris 2 Performance tuning is discussed in detail at http://www.sun.com/sun-on-net/performance.html.
Solaris Network performance is discussed at http://www.sun.com/blueprints/tools/nddconfig and http://www.rvs.uni-hannover.de/people/voeckler/tune/EN/tune.html.
HP-UX Tuning Tips
Netscape Messaging Server can be run on any system running HP-UX 11.0 (PA-RISC1.1 or better).
To determine what your box is, search for the model name in the /usr/sam/lib/mo/sched.models file.
Netscape Messaging Server on HP-UX requires:
Certain kernel parameters may be tweaked to optimize performance. These kernel parameters are described in this section and they must be set manually; HP-UX system administration tools (sam, kmtune) will not allow numbers to be set this high. To set these parameters, edit the /stand/system file. After modifying this file, run the following command to build the new kernel:
# mk_kernel -o /stand/vmunix
and then reboot the system.
The parameters and the values to which they should be set are listed below:
These numbers should serve as a baseline for kernel tuning; they are slightly higher than the recommended numbers for safely using a 128MB C160 (workstation class machine). If you set the numbers too high, your system will exhaust lockable memory, and it will fail to start up properly (network tracing and logging daemons will be the first to complain, and X will not work).
Note: For workstation class machines with only 128MB of memory, the maxfiles_lim, nfile, and ninode parameters should be helf the values listed above; they should be 16384, 32768, and 16384, respectively. It is unlikely that such a workstation could support the mail load that would require the high file values.
Netscape Messaging Server requires many intra-process resources, but comparatively few global resources. For this reason, nproc, nusers, and other similar system-wide resources can be left low to free up memory for inode and thread structures. the exceptions to this rule are nkthread, nfile, and ninode, which also restrict per-process limits.
Many of the ndd parameters listed in the Solaris Tuning Tips section would also be appropriate for HP-UX systems. HP-UX maintains a separate configuration file, /etc/rc.config.d/nddconf, to isolate ndd settings at system startup. The parameters tcp_keepalive_interval and tcp_conn_req_max (equivalent to tcp_conn_req_max_q) can be set as described. The xmit/recv values are already at those levels on an HP-UX system.
Other HP/UX tuning parameters which may be useful to review include:
STRMSGSZ dbc_min_pct dbc_max_pct maxfiles maxswapchunks maxuprc maxusers nflocks nproc nstrpty num_tachyon_adapters ncallout shmmniAIX Tuning Tips
On AIX 4.3.2, you must acquire and install AIX patch PTF U463922 on the installation machine before installing the product.
Without this patch, the extracting file messages are not displayed during installation.
IBM provides patches from the web site http://service.software.ibm.com/cgi-bin/support/rs6000.support/downloads/.
For Messaging Server 4.0x, AIX requires that the minruncount tuning parameter service.smtp.mailbox-deliver.minruncount be set to 1. To do so, run the following command:
# configutil -o service.smtp.mailbox-deliver.minruncount -v 1
AIX Tuning parameters are discussed in detail at the web site http://www.rs6000.ibm.com/doc_link/en_US/a_doc_lib/aixbman/prftungd/tunableaixparms.htm.
Linux Tuning Tips
The system requirements for Linux are described below:
Avoiding Extra Disk Updates
By default, every time a file is read Linux writes the access time to disk. Netscape Messaging Server never uses this information. The partitions that hold the server, stores, and queues may be mounted with the noatime option to avoid these extra disk writes.
Note: These partitions should not be shared with applications that need access time information (for example, tmpwatch).
To make this change, edit your /etc/fstab file. Below is a sample entry:
/dev/sda6 /nsmsg ext2 defaults,noatime 1 2
Low Default File Descriptor Limits
Low system process file descriptor limits may limit the IMAP connection counts. Linux 2.2 with the appropriate patches can support many connections (64,000), but the system limit is often too low.
RedHat 6.0 includes the patches to support 64,000 file descriptors per process. If you are an expert experimenting with non RedHat-kernels, apply the "Alan Cox" patches to get 64,000 file descriptors.
Note: An unmodified Linux 2.2 is limited to 1,000 file descriptors per process.
The following command raises the system file descriptor limit to 80,000:
# echo 80000 > /proc/sys/fs/file-max && echo 80000 > /proc/sys/fs/inode-max
Low Default Process Limits
A low system process limit of 256 per user may limit thread creation for the default server configurations.
Note: Each Linux thread uses a process table entry just like a full process would.
To change this, edit /usr/src/linux/include/linux/tasks.h and change NR_TASKS to 1024 or more and MAX_TASKS_PER_USER to be (NR_TASKS-256):
Rebuild the kernel for these changes to take effect.
Not all the Memory is Used
By default, Linux only uses 1Gb of memory, even if more is available. A portion of that 1Gb is set aside, so only 960Mb is available.
Messaging performance may be enhanced using 2Gb of memory.
Note: Some modules (for example, boot ramdisk) may not work with the larger memory limit.
If you do not specify a 2Gb limit when you configure the kernel, you can edit the following two files are described below:
Tru64 Unix 4.0d, 4.0e and 4.0f Tuning Tips
Additional tuning information can be found at the Compaq Tru64 Unix web site: http://www.unix.digital.com/internet/tuning.htm.
For Tru64 Unix 4.0d and later, the following parameters should be updated in /etc/sysconfigtab:
For Windows NT, you must have Windows NT 4.0 Service Pack 4 or later installed to run and install the Messaging Server 4.15 or later.
|MTA Tuning Information|
Configuration parameters for the MTA are described below:
Even in 4.1x, the SMTP daemon still does not have a maxsessions parameter; it will plex these threads among as many SMTP sessions as it can.
The default for this parameter is 32. For 4.0x, this parameter directly controls the number of active SMTP sessions that can be serviced at one time and that can be safely tuned up to several hundred threads. With the new SMTP thread model in 4.1x, this parameter should be left alone in most cases.
The semantics of these parameters are similar to service.smtp.smtp-accept.minruncount but apply to their respective SMTP daemon modules. In most cases, the default values are fine. When increasing the value of any of these parameters, you should exercise the same care as in selecting reasonable values for IMAP/POP/HTTP servers (see the Protocol Tuning Information section). For example, multiplying all the defaults by 10 would not be resonable, but doubling the number of program-deliver threads on a machine that runs a program delivery mail list manager should be fine.
These parameters turn on or off the logging for each MTA module. The following parameters default to on (yes) if not set:
Our recommended value specifies a language table that only includes languages for which Netscape has resource bundles:
The meaning of this parameter is that each line in service.smtp.domainlangtable consists of:
language-list is an ordered list of languages separated by commas or pipes (|). Currently the ,'s and |'s have the exact same meaning. (We were intending to have the |'s be used when you want to display more than one language (e.g. for a reply to Canada send both English and French), but that never go into the product.) To make your life simpler, it's probably best to just use commas everywhere until functionality changes.
The meaning of a line like:
The From:, To: and CC: lines are rewritten. The overhead is an additional LDAP lookup on the From: address. The To: and CC: addresses should already be cached and no additional lookup is required.
The default value for this parameter is quoted. A value of never turns the header rewriting off.
This parameter controls not only the size of the SMTP LDAP pool, but also specifies the default size of the LDAP pool used by other messaging server processes. Since there is no way to change the LDAP pool size for other processes, this effectively sets the pool size for all messaging server processes. The default for this parameter is 32, which should be adequate in most cases.
Decreasing the value of this parameter may actually help performance in some situations, particularly if you have many IMAP/POP/HTTP daemons since you will be swapping LDAP with too many total connections. However, care should be taken when dropping this number to avoid introducing contention for the LDAP connection among the other working threads. Dropping this value below 8 in most cases is not recommended. Increasing this value by a large amount is usually just a waste of resources.
By default, this value is not set; and works as if set to yes.
These parameters will rewrite the From: and Sender: headers with the information from the authentication session.
These parameters help make sure that connections that are not used and not closed get closed after a certain amount of time.
By default, these parameters are set to 600 seconds (10 minutes). If users are sending large attachments over slow dialup lines, you may need to modify these to avoid connections waiting for threads.
This is the user and group IDs used for program delivery. By default these values are 1, which often corresponds to the daemon use and other group in your local /etc/passwd file.
These parameters describe the error handling when the MTA hop count is exceeded, quota is exceeded, or something unknown happens. These values are numeric sums of the following actions:
Messaging Server 4.x provides two additional ways to stop denial of service attacks along with plugins and filters:
To throttle SMTP accepts, configure the following parameters:
The default value is 100000.
There is no parameter default value; the internal value is 2000.
The MTA will fail to start if it doesn't find a postmaster account, nor will it start if it finds more than one postmaster account. More information is available from http://help.netscape.com/kb/corporate/19990216-3.html.
Routing Multiple Recipients
The SMTP routing is done after the envelope of the message has been split on recipient domains. This means that if you route all mail with one routing rule in a routing table:
*:smtp.otherdomainand send a message to user1@mydomain and userX@yourdomain, then the server sends two messages to smtp.otherdomain: one for user1 and one for userX.
This is probably not efficient if you have a hub or router machine that handles all outgoing mail.
Caching LDAP Queries
Each time an LDAP query is made (on message senders and recipients), the entry info is kept; it is 'tagged' by the search that retrieved the entry (could be either recipient address or UID). This information is kept in memory, roughly tracking the Control information for the message (stored separately, but linked) and removed when the message is delivered or dropped.
Theoretically, this keeps us to one LDAP entry per recipient per message; and most of the time this is the way it works out.
Note: The LDAP information between messages is not cached; it is assumed that there is little chance of random messages containing the same recipients.
For performance reasons, the MTA caches DNS entries. The following describes the impact and process of the caching.
Turning DNS Caching off
Starting with Messaging Server 4.1 Patch 2 and 4.15 Patch 1, DNS caching by the MTA can be turned off if you wish to have more control over the DNS behavior.
The following configuration setting will turn off DNS caching in the MTA:
Customer experience shows that the following should improve performance on outbound SMTP servers. They usually build up to large SMTP Deliver queues causing the server to stop accepting incoming connections. Specifically, the lower setting for smtp-deliver.timeoutgreet and higher setting for smtp-deliver.minruncount are important.
configutil -o service.imap.enable -v no
configutil -o service.pop.enable -v no
configutil -o service.ldapmemcache -v no
configutil -o service.smtp.smtp-deliver.minruncount -v 130
configutil -o service.smtp.smtp-accept.minruncount -v 140
configutil -o service.smtp.smtp-router.minruncount -v 50
configutil -o service.smtp.smtp-deliver.timeoutgreet -v 30
configutil -o service.smtp.account-handler.minruncount -v 40
configutil -o service.smtp.error-handler.minruncount -v 3
configutil -o service.smtp.mailbox-deliver.minruncount -v 1
configutil -o service.smtp.unix-deliver.minruncount -v 1
configutil -o service.smtp.prog-deliver.minruncount -v 1
configutil -o service.smtp.autoreply-handler.minruncount -v 1
setconf local.dbtxnsync 1
Starting with Messaging Server 4.15 Patch 1, you can create a fallback host ("host of last resort") so that if you timeout connections on all of the remote MTAs, you can route messages to a fallback MTA; for example a local MTA that acts as an offline deferred queue.
The following configuration setting will enable a fallback host for the MTA:
If the real MXs for the domain are all dead, these pseudo-MX IP addresses will float to the top and stay there for the duration of TTL (typically).
Trivial case of *:<host> forwards all deferred mail to <host>.
Beginning with Messaging Server 4.15 Patch 1, the ability to turn off LDAP lookups for outbound-only relays is available through the following configuration parameter:
will make everything remote.
In Messaging Server 4.1, the queue handling is designed using a structure based on a directory containing control files and auxiliary directories containing the body of the messages.
The idea is to use status attributes in the control files holding information about:
The queue reporting tool, mailq, performs a count of the number of envelope files in the control directory for a deferred domain and displays that information to the user.
Differences between 4.0x and 4.1x Queueing Behavior
The organization of the deferred directory for SMTP delivery has been changed between 4.0x and 4.1x. Multi-level hash directories have been employed to fan-out domains and message files under queue/deferred/SMTP-Deliver. The hash directories are two levels deep, and is computed for domainname and also for the message files. The hashdir utility can be used to find the hash values.
The deferred queue for the domain netscape.com in 4.0 was queue/deferred/SMTP-Deliver/netscape.com/env-XXX. The 4.1 deferred queue is queue/deferred/SMTP-Deliver/xx/yy/netscape.com/env-XXX, where xx and yy is the hash value computed over netscape.com.
Additionally, in 4.0x when a message was deferred the message file was left in the /messages directory, and only the envelope file was moved to the deferred directory. In 4.1, the message file is now also moved to deferred directory. Ie. queue/deferred/SMTP-Deliver/xx/yy/netscape.com/aa/bb/XXXXXXXX.XXX, where XXXXXXXX.XXX is the message file.
This was changed to minimize the number of files in the messages directory.
Queue Processing when the MTA is Started
On start up, the MTA will attempt a sanity check between contents of the files in the queue/control/env-XXX and the files under queue/messages.
In 4.0x, since we're leaving the message files for deferred messages in the queue/messages directory, a situation could arise where one ended up with many tens of thousands of files in the queue/messages directory (say if a site like hotmail.com is down). This considerably slows down the checking performed by the server at start up. To prevent this situation from occurring the deferred messages are no longer kept in the queue/messages directory.
In 4.1x, since we move deferred message files to their own directory under queue/deferred/SMTP-Deliver, and also since the default throttle limit for the server is 2000, we should rarely, if ever, end up with a situation where there are 20,000 message files in the messages directory.
It is conceivable that this processing could be done in the background, but this is not the way 4.x has been architected. Also it is questionable to start the MTA without doing a sanity check first.
Note: The deferred queue is not processed on start up.
If a message is received with only one (envelope) recipient, then the MTA will put the recipient address into the Received: header. For multiple recipients, it adds no extra information.
For example, the following is what you may see for a single recipient:
Received: from yourdomain (yourmailserver.yourdomain [XXX.YYY.ZZ.AA]) by anotherserver.yourdomain (Netscape Messaging Server X.Y) with ESMTP id AAA5555 for <email@example.com>; Fri, 14 Jan 2000 15:00:00 -0700while for multiple recipients, you would see:
Received: from yourdomain (yourmailserver.yourdomain [XXX.YYY.ZZ.AA]) by anotherserver.yourdomain (Netscape Messaging Server X.Y) with ESMTP id AAA5555; Fri, 14 Jan 2000 15:00:00 -0700Language criteria for Replies
The Messaging Server uses the following criteria for determining the language of replies:
The sendmail utility is a fixed command located at /usr/lib/sendmail which is part of the Messaging Server. Since multiple instances of the Messaging Server can be installed, but only one of /usr/lib/sendmail, this causes issues with which sendmail utility to use.
Starting with Messaging Server 4.05 Patch 1, 4.1 Patch 2 and 4.15 Patch 1, the following configuration parameters are now available for use by the sendmail utility:
The sendmail utility now does the following when looking up its listen address and port number:
|Protocol Tuning Information|
Configuration parameters for protocol tuning are described below:
Because of the problems with this layer of LDAP caching, we have implemented LDAP caching at the mail server application level. There are not that many direct controls into this cache; in particular, what gets cached by the SMTP daemon.
The default values for these parameters was 1,000 in Messaging Server 4.0 and 4.01. This was determined to be too high and was reduced to 250 in versions 4.03 and later. This parameter should be less than 500 under normal conditions to avoid practical problems with thread scheduling and resource contention within a process. If more threads are required, see the numprocesses parameters below.
For Linux, the value of these parameters should be set to 50 to better work with the default process table size.
Note: This does not affect the maximum number of concurrent connections that the servers can sustain.
The default value for these parameters is 1, which should be fine for small to mid-sized servers. This number can be increased on large servers to take advantage of multiple CPUs in a more efficient manner than can be achieved by increasing the number of threads to a very large number.
The increasing the number of processes, you should bear in mind that LDAP pools and authentication caches are not shared across processes. Also, when increasing the number of processes, 1-2 processes per CPU is a practical rule-of-thumb upper limit. Beyond that, the server may thrash under load as processes are thrashed in and out of CPU instruction and data caches. Other servers (such as LDAP servers) that may be running on the mail server should be taken into account when choosing values for these parameters.
The value for this parameter should not exceed the number of processors on your hardware.
The value for maxsessions can be greater than the number of threads. The 4.x server uses a worker thread dispatcher rather than a thread-per-connection model. This differs from 3.x servers which used one thread in one process per session. And in 4.1x, the server allocates threads only to handle each command, so there's a very efficient use of resources.
The default values are 600 for POP and 400 for IMAP and HTTP.
Messaging Server 4.x supports telemetry gathering for the POP, IMAP and HTTP protocols. This tracing involves creating a log file with all protocol commands both sent and received by the server.
Telemetry gathering is done on a user-by-user basis, so create a subdirectory (e.g. log/pop/telemetry/userid) with the appropriate permissions, and a new file will be created there for each connection listing the commands for that session.
Most operating systems support tracing the protocol on a particular socket or port. On Solaris, this is done using the snoop command.
For example, to trace a POP connection, you might use the command:
snoop -x 56 port pop3Read the man pages for these commands before use for details.
IMAP Memory Footprint
Messaging Server 4.1 and later supports thousands of connections per process (the default is only one imapd process).
To be conservative, expect 100K per connection, but in reality this is more like 50K (without SSL).
The nsmsgDisallowAccess LDAP attribute exists for each user and specifies which type of access is not allowed for each user. Set this attribute to pop, imap, smtp, or http as necessary to disallow that type of access for the user.
The service.smtp.domain parameter specifies the domain on which this server runs; it is set during installation. The service.smtp.defaultdomain parameter specifies the domain that users are expected to have if none other is specified; this parameter is set through the Console.
For example, suppose you have a server inside of Netscape that handles mail for customers exclusively; it is called mozilla.com. Thus, service.smtp.domain will be netscape.com but service.smtp.defaultdomain will be mozilla.com.
Specifying Local Domains
Though the ability exists (now that the 2KB limit on entries through the configutil utility has been fixed) to add many thousands of entries to the service.smtp.smtp-router.localmaildomains for a single server, it's not recommended to add more than a couple of hundred localmaildomains. Customers who have multiple thousands of localmaildomains specified may run into performance problems with SMTP routing.
When setting the quota for a user, the quota of the user's mailbox only gets updated on the next incoming message to the mailbox.
You can specify unlimited quota using the IMAP protocol command:
tag SETQUOTA "user/whatever" ()
Aging Rules and Policies
Aging rules can be written on a per-user basis because it's available through pattern matching. For example, you can match on /user/bob/* to match all of bob's folders. This will impact performance with a large number of wildcard matches, however.
Also, there is no current method to build aging policies so that you can specify 100 messages in all of bob's folders. For example, you cannot have the policies activate at a 100 message limit if there are 100 messages in bob's Inbox and 0 messages in bob's Work folder, as well as activate with 50 messages in bob's Inbox and 50 messages in bob's Work folder.
When setting the service.listenaddr parameter for specifying the address which services should listen to, the parameter can be in both hostname or IP formats. Whether the interface is virtual or physical doesn't matter.
|Messenger Express (WebMail) Tuning Information|
Configuration parameters for Messenger Express (WebMail) are described below:
If you have a reverse proxy requirement, where the clients will not be connecting directly with the daemon, you will probably need to disable (set to no) this parameter. Note: disabling this parameter will not restrict the session ID available to the authenticating IP address.
There are several LDAP attributes used by WebMail. Some of these are defined here:
WebMail uses the LDAP language extension. This is the only way in which it can let the MTA know which language to use for auto-reply messages, for applying the appropriate MIME encoding for header and body.
More information about the LDAP language extension can be found at: http://www.cis.ohio-state.edu/htbin/rfc/rfc2596.html
|Security Tuning Information|
Configuration parameters for security are described below:
The default value is 900 seconds, which is on the short side. With the average POP client performing POP checks every 10 minutes, this value would result in an LDAP search being done for every other POP check. Typically, values on the order of a few days are recommended for ISPs.
The authentication cache is not persistent across server restarts, and it is not shared between different processes.
The value of the authentication cache is reduced if proxyauth is used for final user login to the mail store machines as may be the case in some Multiplexor configurations.
The default value is 10,000 entries, which is fine for servers with user populations smaller than 10,000 users.
Data stored here is necessarily temporary; state is not kept over server restarts.
Authenticated SMTP can be enforced within specified domains by using the service.smtp.authmaildomain parameter. This is a space-separated list of entries and can only be set by IP address. (Domain names are either spoofable, or take too long to look up in DNS.)
Partial IP addresses are implicitly "asterisked," and exceptions can also be entered by starting with a !. If finer tuning is needed, a bit mask can be entered after the restricted IP (separated by a tab).
202.11. will require any IP address 202.11.x.x to AUTH before sending mail (NOTE: the trailing . is needed on 1 or 2 digit octets, otherwise 202.111.x.x will match, which is probably not what is wanted.)
202.11. !188.8.131.52 will allow 184.108.40.206 to connect without AUTH even though it's in the above domain.
You may also specify a mask, for example:
202.11.170.<tab>255.255.240.0 will restrict logins from (hex) CA.11.Fx.xx to be authenticated.
Specifying Mailbox Access Domains
The mailAccessDomain filter syntax is:
Or, to restrict the MMP to a SUBNET/IP range, but leave the store open, if it's behind a secure lan:
If you do not know a user's password, it is possible to authenticate against the message store so that you can select a mailbox to check for new messages. To do so:
The Authentication SDK is discussed in the Plugin section.
|Store Tuning Information|
Configuration parameters for the store are described below:
The dbtmpdir parameter controls where these cache files are placed, and should be placed on a RAM backed file system on operating systems that support this feature (for example, /tmp/msg_dbtmpdir on Solaris). Note: this is unlikely to greatly improve performance for running the reconstruct utility.
The performance gain for store.dbtmpdir will only be felt if you have greater than 100,000 users, a correspondingly large data.db2 file (say greater than 50MB) and you've started to increase store.dbcachesize to compensate (say something greater than 100MB). This is exactly the same mechanism used in directory for storing the cache on a tmpfs to avoid excessive and unnecessary page-outs of data that is inherently volatile and deletable.
To know if you need this, look for high wait-times and lots of write io's on your disk volume containing mboxlist.
This parameter is not applicable for the 4.01 server, as it was added to 4.03 and later patches to correct problems in the 4.0 and 4.01 servers. The default value is 1000. For large machines, this value should be set between 100-200. For small boxes, this value should be left at 1000 or even increased.
The 4.x mail store does not unlink message files as soon as they have been deleted via IMAP expunge or POP delete. Instead, the server keeps track of all the messages that have been placed in a deleted state and unlinks the files at the specified hour. This was done to improve performance during peak server usage since unlink() is a potentially slow action executed in filesystem (kernel) space.
For IMAP servers, this expire run normally deletes a relatively small percentage of the messages in the mail store.
On a POP server, this nightly expire run can potentially delete a very large percentage of the messages in the mail store since POP is a download-and-delete protocol. This can translate to several hours of intensive filesystem activity during the expire run, so care should be taken when selecting a value for the parameter to avoid loading the system during peak usage hours.
The default value is 23, which specifies that the expire run should occur during the 11:00pm hour. Finer specification beyond specifying what hours to run is not possible.
The default value of 23 is appropriate for enterprise deployments where the server sees very little usage at night. For an ISP, an off hour such as 03 (3:00am) may be more appropriate.
Starting with NMS 4.03, and included in the 4.1x and later releases, the Messaging Server writes all messages in fdatasync() mode.
This includes messages in the queue, envelope log information, messages written to the store, and metadata within the store, including indices, cache, etc.
Using the following configuration parameters, it can be modified to either using the fsync() mode or no syncing at all (allowing filesystem syncs to handle all issues):
local.dbtxnsyncThis parameter will turn off calling the fdatasync() routine that causes transactions to be synchronized to disk everytime a transaction occurs and allow the filesystem/drive array to schedule the syncs itself.
local.store.messagesynclevel local.store.cachesynclevel local.store.indexsynclevel local.store.expungesynclevel local.store.perusersynclevel local.store.subscribesynclevel local.store.synclevelThese parameters can be set to a value of 0, 1, or 2.
While local.dbtxnsync applies to all database transactions, the local.store.* parameters apply to the store indices and values.
If set to 0, all writes related to file descriptors used by the store are sync'd according to the OS and filesystem.
If set to 1 (the default), all writes related to file descriptors use the fdatasync() command, which forces all currently queued I/O operations associated with the file descriptor to synchronized I/O data integrity completion.
If set to 2, an fsync() moves all modified data and attributes associated with the file descriptor to a storage device guaranteeing that all in-memory modified copies of buffers associated with the file descriptor have been written to disk.
Note: If local.store.synclevel is set, then by default (unless specifically overwritten), the other local.store.*synclevel parameters will use that value.
local.service.smtp.envelopesynclevel local.service.smtp.messagesynclevelThese parameters can be set to a value of 0, 1, or 2, as noted above.
While local.dbtxnsync and local.store.* apply to all database and store transactions, respectively, the envelopesynclevel and messagesynclevel apply only to the MTA. With a higher synchronization level, you will have worse performance, but if data integrity is the most important issue, then turning up the synchronization level may be what you want.
(Please review your system's man pages for more information on what fdatasync() and fsync() mean.)
Single Copy Message Store
Unlike Single Copy Message Store (SCMS) capabilities in NMS 3.x, the NMS 4.x has SCMS that works and cannot be turned off.
It is implemented as hard links on both Unix and NT, and can be archived using normal filesystem utilities. The reference count is kept by the filesystem, not the Messaging Server. The message size is counted towards the quota of each mailbox that contains a link to the message file.
reconstruct and Message Store Maintenance
reconstruct is a utility used to rebuild data in the message store. The message store consists of a master mailbox list (mboxlist) and individual user folders and messages. Each entry in the mboxlist corresponds to a folder in the specific user area.
reconstruct as well as reconstruct -r is used to rebuild the individual user folders in case they become corrupted or inconsistant. (The -r option specifies a recursive reconstruct on user folders.)
Damaged user folders are usually detected from errors in logs, as well as actual user reports and complaints.
Joe1 reports that he can not access his messages in his INBOX. The system otherwise appears to be working properly. Therefore the admin would assume the folder has become inconsistant and run the following:
reconstruct -m is used to rebuild the master mailbox list (mboxlist).
The mboxlist is protected by a logging database, and is thus difficult to corrupt. After a mail server crash or system crash, the mail server will automatically attempt to recover itself. During this recovery period, you may get a warning message that the message store has not come up in the expected time period. If stored is running, it is likely still in the recovery process. If stored is not running, you should check the stored log file as specified by the warning message.
Do not try to restart the store daemon.
Most likely the recovery process will succeed and the store will come up. If it does not, the log files will indicate you need to run reconstruct -m.
In order to run reconstruct -m in this particular situation (catastrophic failure of the database system) you need to keep the store down, delete the contents of the store/mboxlist directory, and run reconstruct -m.
Besides (in addition to) catastrophic recovery, reconstruct -m is also used to resynchronize the mboxlist with the user folders.
The mboxlist is the absolute definition of which user folders are valid. Therefore, if a user folder exists in the store, but is, for some reason, not recorded in the mboxlist, the user will be unable to access this folder.
Currently this situation may be the result of some restore functions as described in backup/restore. Although unlikely, it may also happen in the case of rare system failures. The symptoms are that the folder physically exists in the store, yet it can not be accessed through the server, and reconstruct claims it does not exist.
In this case, you would run reconstruct -m on a running store WITHOUT removing any files as described under catastrophic failure. reconstruct -m will sift thru all existing folders without much interference to normal operation, and resynchronize existing folders into its database.
Now that the mboxlist knows about the folder, a reconstruct can be run on the specific folder in order to make sure the folder is rebuilt correctly.
Looking in the joe1 directory in the message store, it appears as if there is valid data there. Thus we conclude the joe1 folder is not in the mboxlist database, and run a reconstruct -m.
Then we run a reconstruct user/joe1/INBOX to make sure the folder is consistent.
In this extremely unlikely case, we know the mboxlist database is damaged. So following normal proceedures, we would do the following:
Excepting hardware failures, the two leading causes of message store corruption are lack of disk space and manual manipulation of files.
Disk space is absolutely required for a mail server to function as desired. Running out of disk space often leads to administrators trying to move files around and sometimes manually removing them. This very frequently results in some type of corruption.
If you can avoid these two things, there is a very high probability you will avoid some VERY undesirable situations.
Deleting Orphaned Mailboxes
Orphaned mailboxes (formerly active mailbox accounts that have had their LDAP entry deleted) can be deleted with the following two-step process:
The actual commands themselves look something like this:
mboxutil -d /user/test/annie/INBOX
|High Availability Tuning Information|
VxFS to Prevent Kernal Map Fragmentation
Noticeable performance slowdowns may be experienced when running Veritas File System (VxFS) 3.x on large memory (more than 1GB RAM) machines. The fragmentation occurs after VxFS allotts large amounts of memory for buffer cache use due to an immediate need and then frees the buffers when they are no longer needed. This occurs most commonly after a backup process has been run on a file system.
This issue affects all users who match all of the following criteria:
To determine if you have a kernel map fragmentation problem, use the following command:
# echo "map kernelmap" | crash | grep SEGMENT
If the total number of segments returned by this command is over 5,000, then the system is most likely experiencing a slowdown during memory allocations which can affect general performance.
Veritas inode Issues
One of the benefits of the VxFS file system is the promise of unlimited inodes; the ability to create an unlimited number of directories and files in a file system. However, VxFS has a bug that could limit the number of inodes to just over 8 million.
To overcome this limitation, you can do one of the following:
# /usr/lib/fs/vxfs/fsadm /data
This command returns either nolargefiles or largefiles. If nolargefiles is returned, change the setting with the following:
# /usr/lib/fs/vxfs/fsadm -o largefiles /data
The fsadm command should be run while the file system is mounted. It will not disrupt the normal operation of the file system.
VxFS Tuning and Support
For Veritas support and tuning issues you should visit: http://support.veritas.com/.
Directory Server failover
You can specify multiple LDAP servers for failover conditions if one of them goes down. To do this, you need to specify multiple LDAP servers in the local.ugldaphost parameter and set the local.ugldapuselocal parameter to yes.
For example, if you specify:
configutil -o local.ugldaphost -v "ldap01.yourdomain ldap02.yourdomain" configutil -o local.ugldapuselocal -v "yes"then if ldap01.yourdomain becomes inaccessible, it will fail over to use ldap02.yourdomain.
Implementing RAID for Messaging
The recommended method for implementing RAID for messaging is to stripe first, then mirror.
With the many areas of storage used by the Messaging Server, it has been found that RAID 0+1 for the message queue(s) and a hardware RAID5 solution for the mail store (software RAID being slow) works for some customer configurations.
|Backup and Restore Information|
Backup Tips and Information
You can backup your file system either live or from a snapshot; either method will serve to get the bits on tape. For recovery, you should shut down the server and restore the message store from tape, plus any incremental backups.
If you're restoring everything, you should wipe out the mboxlist database and then run reconstruct -m to restore the mboxlist information and the quota information.
If you did not perform the backup from a snapshot, you must run reconstruct -r to rebuild the index files in each folder.
Restoring a Single Message
To restore a single message, locate the #.msg file and use the deliver utility to push it back into a folder. Then run the following command:
reconstruct -r <mailbox>
where <mailbox> includes something like user/<userid>/inbox.old.
Restoring a User's Inbox
To restore a particular Inbox:
where <mailbox> includes something like user/<userid>/inbox-old.
To restore a single folder, move the folder from the backup tape to the user's directory (for example, partition/primary/=user/<hashdir_result>/<userid>/inbox.old). Then, run the following command:
# reconstruct -r <mailbox>
where <mailbox> includes something like user/<userid>/inbox.old.
a User's Messages
The following details a temporary workaround so that a user (mrobinson, in this example) can get access to his/her mail:
Note: Do not copy the store.* files; leave the ones that already exist in =restored.
This may be run while the server is up. The messages should now be in the user's restored folder.
|MTA Plugin and UBE Information|
Plugins are discussed at:
Authentication SDK (ProxyAuth) information can be found under your Messaging Server installation at <server-root>/bin/msg/authsdk/.
Issues related to writing plugins include:
A very important distinction here is that authentication may only happen once.
return PP_DONE and don't DEFERLINE. Remember, the real server is at the bottom of the stack.
|Install and Upgrade Information|
Installation and Upgrade
Installation is discussed in detail at:
When using the upgrade utility with the -r option to remove messages, it first converts the file from Messaging Server 3.x format to 4.x format; if successful, it removes the 3.x file, and then moves onto the next file for conversion.
© Copyright 1999, 2000 Netscape Communications Corp., a subsidiary of America Online, Inc. All rights reserved.