The Storage file watch consumes CPU resources.

Article:TECH203196  |  Created: 2013-02-25  |  Updated: 2014-02-24  |  Article URL
Article Type
Technical Solution


Storage File Watch increasingly consumes CPU leading to an eventual reboot of the system.


There is no error regarding this issue, but the following behavior can be witnessed in a dtrace of storagefilewatch and restarting the 'Storage Service':

65017 16:47:55.256 [3892] (StorageFileWatch) <3812> EV:L {NoteRenderer::RenderNoteAsTextMIME} (Entry)

Notice how this function has an ' {NoteRenderer::RenderNoteAsTextMIME} (Entry)' with (Entry) notation at the end of the line, but there is no corresponding line of dtrace ' {NoteRenderer::RenderNoteAsTextMIME} (Exit)' with an (Exit) notation at the end of the line. This behavior indicates that this function hung. 

Further analysis of the thread ID will identify the problematic saveset that is causing this function to hang.



This issue has been verified in the following configuration:

1) Vault Stores are configured to 'Share within Vault Store'.

2) The problematic partition is a Centera partition with collections enabled.

3) 'Enable device-level' sharing is selected in the properties of the partition.


This issue occurs when StorageFileWatch is traversing the original item (restored from the saveset to a temporary database / NSF) in order to determine if it contains any components that are valid for sharing (Single Instance Storage) on the Centera device.

For specific types of item the  StorageFileWatch thread will hang on the function {NoteRenderer::RenderNoteAsTextMIME}.

This thread will continue to attempt to complete this function indefinitely never releasing the CPU resources. Each time the StorageFileWatch process performs a scan a new thread will come across this problematic item then hang and consume additional CPU resources.

This process will repeat itself until all of the CPU resources are utilized or until the server is rebooted.




Work Around: Identify the problematic saveset(s) that are causing the issue. Rename the item to (i.e. .dvs.old ) Then make a copy of the item and send to support for further analysis.

Upon restart of the Server the StorageFileWatch process will be unable to find the item because it was renamed and the process will move on to the next item.


Resolution: To resolve this issue upgrade the Lotus Notes Client on the effected (EV) server to Lotus Notes 8.5.3 FP3.


Note: Lotus Notes 8.5.3 FP3 on the (EV) Server is only supported with Enterprise Vault 10 SP1 and later.

Supplemental Materials


StorageFileWatch process consumes all of the CPU and the server must be rebooted every 3 days.

Article URL

Terms of use for this information are found in Legal Notices