This forum is closed to new posts and responses. Individual names altered for privacy purposes. The information contained in this website is provided for informational purposes only and should not be construed as a forum for customer support requests. Any customer support requests should be directed to the official HCL customer support channels below:

HCL Software Customer Support Portal for U.S. Federal Government clients
HCL Software Customer Support Portal


~Yentl Mintooly
Apr 1, 2014, 10:35 AM
21 Posts

Compacting Log File on Mail Server

  • Category: Mail
  • Platform: Windows
  • Release: 9.0.1
  • Role: Developer
  • Tags:
  • Replies: 6

Hi,.

I have noticed that the log.nsf file on our mail server is 3.5 GB in size and % used is only 6.2.

Does log.nsf need to be compacted manually .. ? As I presume it is not accessible when server is running .. ?

Also, with a log file of this size, will that have any impact on performance of mail server ..?

Many thanks

Andy

~Phil Nonhipigenikle
Apr 1, 2014, 7:30 PM
26 Posts
rename

you should have a standard process to deal with this.  many people run a script to down the sevrer, rename the log then let the server create a new one on startup.  run compact against the old log that you just renamed since the servr will not be holding it open now.  you can also write a script to stop the server and run compact offline then start the server back up again.  as they say, more than 1 way to skin a cat (no PETA comments).

~James Revelulyader
Apr 1, 2014, 7:41 PM
145 Posts
Several options available
With 9.0.1, you can simply schedule a program record say every 30 or 60 days in a Maintenance Window to run


compact log.nsf -REPLICA -RESTART

which will use compact replication to effectively compact the database... The Server remains up while the new replica is created, once it's completed it will automatically restart the Domino Server and swap the in the new replica on restart

Alternatively you could use an indirect file.

Create a system.ind file containing a list of system database

e.g.
system.ind contains
log.nsf
names.nsf
admin4.nsf


and then have your program record do the following

compact system.ind -REPLICA -RESTART -# 3

which says use 3 separate threads to compact the databases in the .ind file...


Compact Replication is smart enough to not restart the server until all 3 of the databases have been compacted.

Regards,
John Pag

jpaganet@us.ibm.com


~Xagra Minponeburobu
Apr 2, 2014, 12:50 PM
9 Posts
log.nsf space waste, compact and server availability
With respect to log.nsf and compact the following feature (compact -replica) is specifically designed for databases like log.nsf to allow maximum server availability and only restarting the server for a brief moment to rename the physical file and do an incremental sync of notes.  This might be generally helpfull for a best practice.

http://www-01.ibm.com/support/docview.wss?uid=swg27039379

This will help recover some wasted space with respect to some internal meta-data.

But, this is not necessarily the issue you are seeing.   The big issue with log.nsf has been as follows.

There was a change to adjust the size of the notes generated by the log events in Domino (V853FP4++) to form at least 2 notes per bucket (yes the summary portion of notes go in 64k buckets and the log events need summary data for view inclusion).  Earlier versions unfortunately the sizing was such that each note took slightly more that 1/2 a bucket...with obvious consequences.

What is the following line in your notes.ini?

Log=log.nsf, 1, 0, 7, 30000, 0

The 30000 indicates roughly the size of the note to generate for the "screenfull" of events you see.  At 30k 2 notes can fit in a 64k bucket (minus some overhead).
I actually prefer a smaller size from a user perspective also so I can browse through the logs without scrolling up/down on each page presented.
But, this is not only a UI convenience, it has effects on bucket space usage.  Also, it can not be > 48k due to notes Editor constraints.

the default used to be:

Default: Log=LOG.NSF,1,0,7,40000

so about 20k per bucket wasted.

There might be the case of residual data in the log.nsf that will remain and block the effectiveness of a  better setting of 30k even if compact is run to reorganize the notes in the buckets (which will not help.)  In which case you will need to generate a new log.nsf from scratch and then you should be good moving forward.   Or, if you really want to retain the data in log.nsf, you can set the size to something smaller like 15k-20k and let that run for a while.   At which point compact should eventually fill in the buckets to be almost full.  Not worth the effort in my opinion.
The easiest  is obviously to clean the slate and move forward.
~Sigmund Dworelitnivu
Apr 2, 2014, 6:15 PM
328 Posts
Is this information going to get updated in the notes.ini reference?

One of my pet peeves with Lotus support is the fact that the Notes.ini information at http://www-10.lotus.com/ldd/dominowiki.nsf/dx/Log isn't kept up to date, has many, many missing parameters, and, in the case of working with support troubleshooting an issue find that in many cases seems to just be plain wrong.

Don't MEAN to complain, but it would sure be helpful if the documentation was correct and kept up to date.

Thanks!

 

~Xagra Minponeburobu
Apr 15, 2014, 1:59 PM
9 Posts
Please Make Noise
I am in development and I agree with you 100%

Besides the documentation that needs to be up to date, we really need a more dynamic approach.   I started to implement one day....before I got sidetracked... a mechanism to show the default/current setting on a server.   What I mean is you can always "show config" and show the explicitly set values.  What you do not know is the implicit default values that are currently running for the ini settings you did not set.   And, to make matters worst these can change from version to version.  I was thinking a "show config default" and "show config current" or something of that order.
~Sigmund Dworelitnivu
Apr 15, 2014, 2:45 PM
328 Posts
I like it...

I like it!!   Or possibly combine the two.. 'show config' could show the setting with the default value in parenthesis or brackets - for example 'show config CleanupTimeout' might return: 'CLEANUPTIMEOUT=600 [5]' (or: 'CLEANUPTIMEOUT=600 [Default: 5]'). If the setting didn't exist in notes.ini - the server might return 'CLEANUPTIMEOUT=<not set> [Default: 5]' or something similar.

On my original subject - I realize how monumental a task to update the Notes.INI reference on the web - but IBM was the one that removed it from the version documentation to keep it on the web 'where it can be kept up to date' (not I), and, exactly as you stated - it varies from version to version - so as a user we upgrade a server - over time the darn server's notes.ini gets way out of whack. Trying to get it back into whack can be a daunting task. I've literally had PMRs go for days just trying to nail down one or two specific Notes.ini parms after being told to set them, checking the 'documentation', and finding a conflict.

Fortunately I've been off on a different project and haven't had any mail issues for awhile - but one of these days I have servers to update...

 

Thanks for your thoughts - i do like it!

 

 


This forum is closed to new posts and responses. Individual names altered for privacy purposes. The information contained in this website is provided for informational purposes only and should not be construed as a forum for customer support requests. Any customer support requests should be directed to the official HCL customer support channels below:

HCL Software Customer Support Portal for U.S. Federal Government clients
HCL Software Customer Support Portal