The most common bottleneck in PMDF is disk I/O. PMDF does a lot of it. Try to keep the disks with PMDF's message store below 66% capacity so that the operating system can efficiently manage file create and delete cycles. This is especially important on OpenVMS where the file system begins to become very inefficient once the disk gets over 66% capacity. Also, use disk striping or other aggregate disk spindle techniques that help both read and writes. Avoid disk shadowing if possible. Disk is cheap these days: spend money on multiple spindles and sufficient free space.

By using symbolic links under the /pmdf directory (UNIX), or by redefining the PMDF_QUEUE and PMDF_LOG logicals (OpenVMS) you can redirect where PMDF keeps its message store and log files. PMDF's command, executable, and table directories² can also be separated if absolutely necessary.

The location for PMDF temporary files can also be moved. PMDF_SCRATCH controls the location of temporary unnamed files (such as those used to buffer incoming large SMTP messages or incoming large messages submitted by local users); PMDF_TMP controls the location of temporary named files (such as those used by the conversion channel). On UNIX, both values default to /pmdf/tmp if not explicitly pointed elsewhere in the PMDF tailor file. On OpenVMS, if PMDF_SCRATCH and PMDF_TMP logicals are not defined then temporary unnamed files default to SYS$SCRATCH (next SYS$DISK, next SYS$LOGIN) and temporary named files default to PMDF_QUEUE:[000000]. Note that if explicitly defining PMDF_SCRATCH it is important to point it to a device on which any user can create files.

By default, the messages for a given channel are stored in a single, channel-specific directory under PMDF_QUEUE: (OpenVMS) or /pmdf/queue/ (UNIX) or usually C:\pmdf\queue\ (NT). File system performance degrades rapidly for directories with more than a couple thousand files; this can present a problem for channels which see heavy message traffic --- especially when the network associated with that channel is down and messages begin to queue up. Use the subdirs channel keyword to indicate that a channel should uniformly spread its messages across several subdirectories. For Internet sites with heavy traffic loads, this should be done for their outgoing TCP/IP channel, usually tcp_local.

By changing the PMDF_QUEUE_CACHE_DATABASE logical (OpenVMS) or PMDF tailor file option (UNIX) or Registry entry (NT), you can move the queue cache database to an alternate location. After moving it, be sure to issue the OpenVMS commands

$ PMDF CACHE/CLOSE $ PMDF CACHE/SYNCH

or the UNIX commands

$ pmdf cache -close $ pmdf cache -synchronize

or the NT commands

C:\> pmdf restart dispatcher C:\> pmdf restart job_controller

so as to ensure that all PMDF processing jobs close the old database and begin using the new, relocated database.

It is safe to keep the queue cache database on a virtual RAM disk provided that:

1. You periodically copy the queue cache database to a regular disk. (On OpenVMS, use BACKUP/IGNORE=INTERLOCK to make a copy of the queue cache database on a running system.)
2. You resynchronize the queue cache database each time you reboot your system. On OpenVMS, use the command PMDF CACHE/SYNCHRONIZE, and on UNIX and NT, use the command pmdf cache -synchronize. The cache resynchronization should be performed after executing the pmdf_startup.com procedure (on OpenVMS) and before starting your networks or PMDF processing queues.

High volume sites that have enabled the logging channel keyword to log message traffic, as well as the LOG_CONNECTION PMDF option to log connections, can want to enable the SEPARATE_CONNECTION_LOG option to direct the connection log entries to a separate file from the message traffic log entries; see Section 7.3.6. On OpenVMS, busy sites that have enabled the logging keyword can also find it beneficial to increase the LOG_ALQ and LOG_DEQ options, also discussed in Section 7.3.6, to use larger file extents for the underlying file allocation.

UNIX and NT sites can consider whether for their use it is acceptable to set the PMDF option FSYNC=0. Doing so improves performance, but at the cost that if a UNIX or NT system crashes at just the wrong moment, messages not yet synched to disk could be lost. See Section 7.3.8.