From time to time I have some issues with my Notes Client. In almost every case these issues occur when the CACHE.NDK size is at 30MB.
Bringing the Notes Client down, deleting cache.ndk and let the client create a new file at startup solves the issues.
There is already an entry on IdeaJam to delete the cache.ndk on client startup. (http://ideajam.net/ideajam/p/ij.nsf/0/D599DAE62FA43BBB86257723005994BC). As there is no such option in the client by now, I tried to find a way other than deleting the file manually.
Putting a cmd file into the Windows Startup folder is one option. But I wanted to go one step further. Accessing the cache.ndk does also mean I/O operations on the physical harddrive. OK, I could use SSD, but I do not have an SSD drive in my current environment.
So I decided to give a RAMDISK a try. I found a good one at http://www.ltr-data.se/opencode.html/#ImDisk.
he installer installs he driver as a service, so it can be started at Windows startup. In addition to get the RAMDISK to work you have to create a disk and format it every time Windows starts.
I created a ramdisk.cmd file in my Windows directory and created a shortcut to this file in the Startup folder for all users.
Here is the content:
imdisk -a -t vm -s 300m -m n:
format n: /V:RAMDISK /FS:FAT /Q /Y
The first line creates the disk in RAM ( n:\) and the second line formats the disk.
In addition, I changed my notes.ini file and added
CACHE=n:\cache.ndk
The next time you start your client, CACHE.NDK is created in the RAMDISK. When you shutdown your computer, the RAMDISK is removed and so a new file is created on every client start.
I will now play with some other notes.ini variables that normally perform disk operations to see, what the side effects are.
Urlrich,
Can you please change the URL to your idea to:
http://ideajam.net/ideajam/p/ij.nsf/0/D599DAE62FA43BBB86257723005994BC
Thanks,
Bruce
Link fixed
According to this: http://www.ibm.com/developerworks/lotus/documentation/notesperfstability/ deleting the cache.ndk regularly is a bad idea.
According to Francie of panagenda fame, during 18 years she had one (1) case of where a corrupt the cache.ndk actually was the root cause.
That said, I can see that a cache.ndk on a RAM disk coyuld be a good thing. If it’s big enough, pointing the Notes Temp folder to it should speed up view rebuilds and refreshes really nicely..
Just curious: how big is it set? (in Workspace properties, Beanie tab)
It is set to 5MB. But regardless the setting, cache.ndk grows beyound the 5MB limit. I have seen this in Notes 5 .. 6… 7… 8 …8.02 …8.5.x
never had a problem, when deleting the file at Notes startup. In my former company, we had this in the user profile on logon.
We ALWAYS had problems, when the file reaches the 30MB.
I think one has to realize that the effect of the re-creation of cache.ndk is only a fraction of the overall start performance of a Notes STANDARD client, so the results of Panagenda in regards to cache.ndk are not wrong, but might be overrated.
I agree with Ulrich that there are issues that can most easily be solved by deleting cache.ndk.
Relocating cache.ndk is only the first step, more important is to relocate temp. eclipse client data, e.g. Java Shared Classes cache (already memory mapped), logs, Notes Tempdir, etc…
I think that the workspace size setting applies to desktop.ndk, not cache.ndk. That would explain Ulrich’s findings. The cache.ndk size is controlled via notes.ini property “UserCacheQuotaSize” (30 MB is the default).
The RAMDisk idea sounds quite interesting, please post your findings!
I make even more on every logon:
del “%homedrive%%homepath%\lotus\notes\data\cache.ndk”
del /Q /S “%homedrive%%homepath%\Lotus\Notes\Data\workspace\Local\*.*”
rd /Q /S “%homedrive%%homepath%\Lotus\Notes\Data\workspace\.metadata\.plugins\org.eclipse.core.resources\”