Monday, November 20, 2017

Get those Domino System Databases back in shape with Defrag.NSF

We often see Domino servers with bloated System databases that never seem to get compacted/maintained (you know the ones.... log.nsf, etc) because.....well it's just always been a hassle for many admins to shut down and manually do it. As a result, these databases are missing out on some much needed maintenance and can get pretty huge and often respond sluggishly when they do need to be opened. Usually with many GB of disk space trapped inside they are just wasting disk space too, it all adds up costing time and money, not to mention it can be aggravating for admins or users when they do need to work with these databases and again watch the spinny thing go around upon trying to open one.

By customer request a new feature in Defrag.NSF makes it so easy to apply best practice maintenance, get these back to a manageable size and give Domino a nice scheduled "Health Restart".

Now Defrag.NSF makes this as simple as ticking a few boxes, set and forget, and if this is scheduled once a week the difference it makes to Domino is quite amazing.

During this phase of scheduled maintenance Defrag.NSF integrates with Domino's own maintenance processes by using Compact Replication on the System Databases (and other databases you might want to add) with the Domino server up and running and therefore minimizing down-time, a -Restart is then initiated to complete the rename process.


We see below the system databases are compacted and upon restart the rename process is completed:


Learn more about Defrag.NSF or take it for a free trial here.


Tuesday, June 27, 2017

Domino Database Optimizer Health Check

One of the first things we suggest you do when you install the Domino Database Optimizer is run a Health Check and below is a typical example of what we find.

These screenshot shows a selection of some of the less than optimal results revealed on a Domino 9.0.1 server during the initial DDO Health Check.




A simple button click in DDO will activate the optimizations with no further administrator effort.





Then on schedule, DDO performs tasks according to the administrator's configuration for:

- DBMT automation/Compact/Updall
- Database properties settings
- Automatic DAOS checking and enablement
- NSF files defragging
- Perform an automatic Domino restart and perform System Database maintenance/compacts run
- NIF enablement/View Optimization
- Backup time reduction
- Minimise server I/O and improve performance for the entire system

It's ridiculously simple to do, so why not get a trial from here

.

Friday, April 7, 2017

DBMT still creates fragmented NSF files on volumes that are fragmented

On a busy server Compact -C fragments NSF files left, right and center. It sprays bits of the file all over the place. The only thing we have seen in Domino that does a worse job are full text indexes. 

As previously discussed and referenced by others and IBM,  DBMT does a much better job. It tries to create a contiguous NSF file, but it can ONLY do that it the freespace on the server is not highly fragmented, and the only way that is going to happen is if you have taken steps to keep it in shape (for example by using  DDO or Defrag.NSF). We have covered this before, but here is a recent real world example.

It starts off with a 600MB NSF that is in one piece (thanks to DDO)


DBMT runs on the database (this server has over 1TB of fragmented freespace)



And now we see the results. What was once a single fragment is now 567 fragments.



So in summary DBMT does a MUCH better job than compact -c, but it can still make a mess of things and that is why in DDO we have wrapped DBMT with a bunch of smarts and then incorporated Defrag.NSF in the deal. The results are and will always be much much better.

DDO - Domino Optimized.

Note: Example server was Windows Domino 9.01 FP7 Server, 2.5TB of data. It was a VM using Enterprise SAN storage.

Thanks for reading.

Friday, March 31, 2017

Virtualizing Domino is NOT a "Get Out Of Jail Free" card

Further to yesterday's blog we wanted to point out that recently VMware updated their latest documentation for VSphere 6.5, included is the recommendation to "Defragment the file system on all guests" to enhance Disk I/O performance.

It is so often not understood that fragmentation in the virtualized environment can have a devastating impact on Domino server performance and also the O/S, and yep, we see this a LOT. This negative impact happens because as far as the Guest  O/S (Windows) is concerned it is still working with fragmented files and that causes Windows to issue many more I/O requests to access these files. This creates Split I/O's where unnecessary multiple I/O requests are generated to access fragments of each file and that contributes to I/O bottlenecks with some requests being blocked while other are fulfilled. Basically the end result is Windows still perceives the fragmentation at the file system level and must deal with it the same as if you were running the O/S and Domino server on a physical box.






Fragmentation happens on File System level, regardless of virtualization or storage medium, there's always some impact, and it won't go away simply because you are running Domino virtualized.

Running Domino virtualized or with SAN storage is not a Get Out Of Jail Free card with regard to fragmentation and it's effects, getting the best from your system investment involves optimizing all the components in the "system" and that includes the Guest OS and the Domino server.

Wednesday, March 29, 2017

A simple way to reduce backup times by 55%

Last week DDO went into action at an Australian Coal mining organisation. The server was a mess, with exceptionally long backup times. It is a VM, running on a high powered SAN, but none of that matters, because if Windows sees fragmentation it acts accordingly, it slows down and in this case was issuing millions of additional I/Os to get backups done.

DDO ran and optimised the files.

In the chart below you can see the positive effect of removing 742,289 fragments from just 144 databases. Backup times plummeted from 6 hours, 40 min to just over 3 hours. A fantastic result.



The backups are now faster and the SAN less stressed with everything connected to it more performant.

Find out more about the Domino Database Optimizer.

Update: The server is running 9.01 FP6 and in such a mess that even when DBMT ran, the resultant database became MORE fragmented. More on this later.