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


~Zach Asafreetexings
Jan 27, 2014, 7:36 AM
1 Posts

DAOS repository growing rapidly

  • Category: Domino Server
  • Platform: Windows
  • Release: 9.0.1
  • Role: Administrator
  • Tags: Domino9,daos
  • Replies: 2
Hello,

Since the beginning of January I've noticed that our DAOS repository is growing rapidly, about 1,5Gb extra every day. I've looked on the NLO files and found a large amount of same size files (62.142.324 bytes).

I've moved them out the the repository to see if any error occurs, but everything seem to work fine.

Are there any tools that can help me identify the originating database based on the NLO filename? I've looked at this possible solution

https://www.ibm.com/developerworks/community/blogs/VICTips/entry/using_scripts_to_identify_which_databases_reference_an_nlo_in_domino_daos4?lang=en

but the code just make the NSERVER.EXE go ballistic and no txt files are written.

Any help is much appreciated.

~Fred Umkivitchli
Jan 27, 2014, 5:42 PM
48 Posts
re NLO Growing in size
The large increase of NLO's may possibly due the prune process not completing.
Use "Tell DAOSMgr Status" on server console to see if daos is synchronised state

If "needs Resync"  state you could try ..

( Please make sure all nlo's are backed up before doing ...)

tell daosmgr resync
tell daosmgr status
tell daosmgr prune 0
tell daosmgr resync force

FYI ..
NLO's are cleaned up (deleted) by the DAOS Prune process that is scheduled to run nightly at 2:00 AM.  NLO's are only removed when the DAOS catalog is in a 'Synchronized' state, the NLO refcount is zero, and the NLO was marked deleted longer than the prune interval ago..

For listing which .nlo's are used for a specific database using the following command:

tell daosmgr listnlo -o dbname all dbname.nsf

The following commands are documented in the Domino Administrator Help:

Tell DAOSMgr Quit
Tell DAOSMgr Help
Tell DAOSMgr Status
Tell DAOSMgr Status database_name
Tell DAOSMgr Status Catalog
Tell DAOSMgr Status Dbsummary
Tell DAOSMgr Status Databases
Tell DAOSMgr ListNLO
Tell DAOSMgr Prune 0
Tell DAOSMgr Prune number of days old
Tell DAOSMgr Resync
Tell DAOSMgr Resync Force
~Sigmund Chufanavitchli
Jan 29, 2014, 7:07 PM
12 Posts
Re: DAOS repository growing rapidly
As mentioned, make sure that your DAOS catalog is synchronized, and that prune is running regularly.  The prune interval defaults to 30 days, so that will not be an immediate solution however.

DAOS does not keep track of what NLO is referenced by what NSF files, only a total number of references.  You can see the refs for a given NSF...but you can't get a list of NSFs given an NLO.  

You can get some information about when the NLO files are created using the daos logging diagnostics.  Change the filename/path as desired.  This will trace NLO allocations and the renames to the permanent (shared) filenames:
DAOS_LOGGING=c:\tmp\daos.txt ALLOC SHARE

As of 9.0.x, this is a dynamic setting, and can be altered on the fly using the 'SET CONFIG' console command.  Earlier versions require a cold restart of the API (shut everything down) to pick up a change to this setting.

Other things to check:
- Do you have a consistent encoding/compression setting across all your NSF files?  Best practice is to have everything the same.  DAOS only sees the attachment data after all NSF options have been applied, and determines the key (filename) based solely on the content it sees.  Different encoding (mime, native) or compression (none, huffman, LZ1) will result in different NLO files for what was originally the 'same' attachment.

- Are you runing POP/IMAP clients?  In some situations these will cache MIME-formatted messages in an attachment...which can be large enough to be stored in DAOS.  As they are transient, they've got 0 references, but they still adhere to the 30 day deletion period (or whatever you have configured.)  For 9.0.x, you can enable DAOS_AVOID_MIME=1.  For earlier versions you can request a hotfix with SPR # PPOR8XZLPN.

- What is your minimum participation size?  Setting the size too small can result in far too many NLO files being produced.  For most mail environments 512K-1M is a reasonable value.  The best solution is to run the DAOS estimator and examine your data to see what a good setting for your environment is.  See http://www-10.lotus.com/ldd/dominowiki.nsf/dx/DAOS_Deployment_Guide


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