4.6 Placement of high-use Domino files

< Day Day Up >

In this section we discuss the placement of important Domino databases and files. We point out how the structure of your filesystem can influence the overall performance of your Domino server.

4.6.1 Transaction log

When transaction logging is enabled, the speed at which transactions are written to the log files has a direct impact on server performance. When a transaction (update to a database by an NRPC call) is closed, it is immediately committed to the transaction log. When the transaction has been fully committed to the log, it is marked as "complete". Shortly after this, the changes to the database are built in memory and eventually written to the actual database on physical disk. Because of this sequence, the performance of the device which houses the transaction log determines the overall performance of the server.

The transaction log is made up of a number of 64 megabyte transaction log extent files. These files are written to the log sequentially and almost never read from.

The sequential writing of data ensures that the motion of the heads across the disk surface will be in constant direction with little or no extraneous head movement, hence there is no disk latency. This ensures the absolute best performance, even on older disk subsystems. The disk subsystem must also be able to handle continuous writes at a speed of at least 10 MB/sec.

It is an absolute necessity that the transaction log directory not be placed on a disk with other high-use data, as access to these files would degrade the overall performance of the transaction log. Place the transaction log on a dedicated device and a low-use controller if possible. This recommendation is due to the requirement of being able to deliver a constant stream of transactions to the disk subsystem at the fastest possible transfer rate.

An additional consideration is the fact that the transaction log is now the most important data file on the system. This is especially true if archive style transaction logging is being used. If a database or group of databases need to be restored, they can be brought up to absolute currency by restoring the database from the last full backup, and then applying the transaction logs. If the databases are completely lost due to a disaster, they can always be recovered as long as the transaction log extents are fully intact.

Keeping this discussion in mind, it is best practice to place the transaction log directory on its own mount point. This mount point should be configured on the best performing DASD. Multiple full minidisks or DASD volumes in an LVM should be configured to house the transaction log. The DASD string should, if possible, be associated with channels that are lightly loaded in order to achieve the best throughput.

We recommend that you define a separate (mount point) filesystem for the transaction logs. Together with your DASD administrator, try to make sure that this filesystem is fast and has enough space left for your preferred transaction log operation (archive or circular). If you already have a Domino infrastructure, you can use the server statistics to calculate how many transactions during a day are written by your servers. Also, from the server statistics, find the typical size of the transactions. With both numbers, you can easily set up a filesystem that is large enough to support your Domino environment.

Tip

Enable the fast write cache on your DASD

Fast write cache (FWC) is an optional, nonvolatile cache that provides redundancy with the standard adapter cache. The FWC tracks writes that have not been committed to disk.

FWC can significantly improve the response time for write operations. However, care must be taken not to flood the cache with write requests faster than the rate at which the cache can destage its data. It can also adversely affect the maximum I/O rate, because additional processing is required in the adapter card to determine if the data that is being transferred is in the cache.

Fast write cache typically provides significant advantages in specialized workloads (for example, copying a database onto a new set of disks). If the fast write cache is spread over multiple adapters, this can multiply the benefit.

The FWC can also reduce journaling filesystem (JFS) log bottlenecks because of three properties of the JFS log:

The JFS log is write-intensive. The FWC does not cache unmodified data.
The writes are small and frequent. Because the cache capacity is not enormous, it works best for high-rate small I/Os that are gathered together in the adapter into larger physical I/Os. Larger I/Os tend to have better performance because less disk rotations are normally needed to write the data.
Logs are not typically very large, relative to the cache size, so the log does not tend to "wash" the cache frequently. Therefore, the log loses the benefit of rewriting over existing cached data.

4.6.2 Names.nsf

In most cases, you will accept the default location for the Domino Directory (DD, formerly known as name and address book or NAB), which is the notesdata directory. When grouping multiple volumes together into one logical volume, it is not necessary to have a separate filesystem for the Domino Directory. However, there may be times when it is a good idea to configure a mount point with a dedicated minidisk or volume to hold the Domino directory.

These may include a full-text indexed Domino Directory with frequent indexing, a directory that is being as a repository for user information (such an online company phone and address book), or any other situation where the directory is being heavily accessed. If you do so, you will need a database link for the DD, because by default the server expects the DD to be in the notesdata directory.

4.6.3 mail.boxes

On mail servers, some of the most heavily used and most dynamically changeable databases are the mail.box databases. In most cases, placing the mail.box database within notesdata provides adequate performance to meet most needs.

The other databases in the notesdata directory that get used most heavily are log.nsf and the Domino directory. What you do with those databases also applies to the mail.box databases. If mail performance is determined to need improvement, the mailx.box databases can be placed in a separate filesystem on their own mount point.

The placement of the DD holds true for the mailboxes. In addition to using a separate filesystem, VM offers another choice for files containing data of a temporary nature. Because the data is only kept for a very short time in the mail.boxes, you can place them on a virtual disk. If you do this, be sure you check the mail.boxes for dead mail more frequently. This may not be a viable option if the server is acting as an inbound or outbound SMTP gateway, as mail will sometimes be backed up in the mailx.box.

If you place the mail.box on a virtual disk, you should implement a different shutdown procedure for your Domino servers. First shut down the router, then check the mail.boxes for dead or held mail, copy them out of the mailbox, and then shut down the server. Place mail.boxes only on a virtual disk if you fully understand its use and limitations.

Tip

Make sure the transaction log is disabled for your mail.boxes

4.6.4 Log.nsf and log files for the Java™ Console (dcntrlr*)

Put the log files in a separate directory. This is not a performance hint, but doing this helps you to clean up your notesdata directory. The log files for a remote Domino java console can be configured with an expiration date and therefore be fairly tightly controlled.

4.6.5 Indexing and other temporary files

For performance reasons, we suggest that you place the temporary files for rebuilding the index of a database on a virtual disk. You can force Domino to use a place other than default by setting the following notes.ini variable: View_Rebuild_Index_Dir=your/directory. For the same reason, you can put the directory that your anti-virus software uses for scanning and decompressing attachments on a virtual disk. Also you might think of placing the gtrhome directory on a virtual disk. gtrhome is the directory in which the index engine stores its temporary results from queries, and where it builds temporary indexes when users full text search databases that do not have indexes (usually through one of the APIs or an agent).

Attention:

Be sure to put only non-permanent data onto a virtual disk! It will be lost when the user ID is logged off or the server is shut down.

4.6.6 Use of database and directory links

Both Linux and Domino offer symbolic links for directories and files to databases. We do not recommend the use of Linux symbolic links. But the deployment of Domino database or directory links can help you structure your environment without struggling with the Notes client settings.

For example, you can direct all mail users to a directory called mail. Inside this directory, the database links redirect the user transparently to the physical location of their mail file. To accomplish this, you have to create a database link for every mail database in your system. When deleting or adding a user, remember to delete or create not only the database, but also the link.

< Day Day Up >