Domino @ Symetrik Design » Optimization

compact -S works…sometimes.

david — Mon, 20 Oct 2008 04:45:20 +0000

I’ve recently stumbled upon using compact -S5 in our weekly Saturday compact program document.

Like most shops, we run Fixup on Fridays and then Compact on Saturdays on all databases.

We found that a couple of servers that have about 400GB worth of mailboxes were not finishing their compact jobs. The compact was taking somewhere in the range of 36 to 48 hours. We weren’t sure how long it was taking because we had to shut it down on Monday morning when people got into the office and starting trying to access their databases.

I found the -S switch which will compact only database which will only compact databases with more white space than you specify in the .

Example: compact -S5 will only compact databases with more than 5% white space.

This dramatically cuts down on the time required to run compact because it will skip all of the databases that are already pretty much compacted, but which may be very large.

We went from 36+ hours to about 6 on two of the large servers. This is a great improvement which really works for us.

One strange thing that I noticed though is that is doesn’t always calculate the white space correctly while initializing the compact job. Sometimes databases that are 90% compacted are skipped when you use the -S5 switch.

We are using 6.5.6FP3 HF53 servers.

Does anybody else have experience with using the -S switch and seen the same anomalies?

Performance Improvement – What do these Notes.ini variables do?

david — Tue, 14 Oct 2008 09:35:34 +0000

I was taking a look at this article at IBM.

I noticed that they added these variables to R6.5.x server:
NSF_DBCache_MaxEntries=4100
Server_pool_tasks=60
Server_max_concurrent_trans=60
Server_show_performance=1
Server_TransInfo_Range=9

and these notes.ini variables to 7.0x server:
NSF_DBCache_MaxEntries=4100
server_pool_tasks=60
server_max_concurrent_trans=60
server_show_performance=1
Server_TransInfo_Range=9
Cluster_replicators=3
FTUpdate_Idle_Time=25
Update_Idle_Time=25
EnableForcedFillOnFileExtend=1
NSF_DBCache_Max_Clean_Hold_Time=9999

Just wondering exactly what they do. It would have been nice if they would have explained the benefits of the performance improvement instead of just comparing the two versions of Domino.

Why it is good to seperate the program and data directories

david — Fri, 15 Aug 2008 06:41:14 +0000

In a recent disaster at our organization, we had to restore the program directory of a server. Since someone built the server with the default d:\lotus\domino and d:\lotus\domino\data, the outsource host facility restored the whole d:\lotus directory and it took us 4 hours waiting while the server was down.

This highlights some points that I always try to make about Domino disk installation:

If possible try to have different physical partitions for Domino.
C: drive Mirrored Array (2 physical disks) for Operating System and Domino program files
D: drive Raid 5 Array (3 or more physical disks) for Domino data files
E: drive (single disk) potentially for SWAP file, Domino temp directory, full text index temp directory.
F: drive Raid 5 Array (3 or more physical disks) potentially for transaction log, mail capturing, etc.

You’ll get better performance if the program files are on a disk that is not very fragmented.
You will also have an easier process for backing up your program directory prior to a Domino server upgrade (and if necessary – fall back procedure).
You will also have an easier and faster time restoring just the program directory if your Domino install becomes problematic and you need to do a restore.

Any comments?