Mac lotus notes client set tcp/ip windows#
The documentation about the flag is not really clear on the Microsoft side and the behaviour changed with Windows 2008 64bit. This explains the high cache usage we have seen with Domino also in earlier versions. It turned out that the first file-handle opened with the FILE_FLAG_RANDOM_ACCESS causes that all following file reads of all other processes are stay in the cache for a long time.
I have done a lot of testing with different ways opening files. Especially during a backup of a larger Domino server the file-system cache will grow dramatically and causes performance issues. But it turned out that in Windows 2008 64bit this flag triggers that the file blocks that are read stay in the cache until the file is closed.īecause Domino keeps file open in the Database Cache (dbcache) for performance reasons it takes quite a long time until the cache is released. IBM is using this flag to reduce the amount of read ahead caching because NSF files are more or less read in a random way. The system can use this as a hint to optimize file caching. Domino 7 and higher (also the current 8.5.2 version) uses the following flag to open all NSF files:Īccess is intended to be random. It turned out that Microsoft uses different cache strategies for different ways files are opened. Depending on what fixes you have installed the problem shows up in different ways.Įither you have a temporary high CPU load (without the fixes) or at some point the I/O rate drops dramatically. Still with all the fixes the file-system cache can become very ineffective. But even Win2008 R2 still needs hotfixes which you need to manually apply. Some of the general issues have been addressed in Windows 2008 R2. There have been a couple of issues that caused high CPU load when Windows needed to scan thru all the Virtual Memory pages. So even the data stays in Virtual Memory of the cache manage it might be already removed by the Virtual memory manager because the working-set of the cache manager is far smaller than the Virtual Memory. The total limit is 1 TB even the physical memory might be only a couple of GBs. The biggest limitation we ran into the 1 TB limit for the Virtual Memory used by the cache manager.įor example if you have a lot open files with a lot read activity (for example during a Domino backup) the pages read stay in Virtual Memory of the cache manager. But this becomes an issue when a lot of data needs to be cached. But in normal conditions this is still not a big issue because the file-system cache should not grow too much. IMHO this is not how a cache manager should be implemented. But on the other hand, if the Virtual Memory for the file-system cache becomes larger and larger the Virtual Memory manager will throw out many pages but keeps the open files still in the Virtual Memory of the File-System cache. The amount of memory is the working set of the cache manager specified via the SetSystemFileCacheSize Windows API call.ĭomino 8.5.x sets this value by default to 30% of the physical memory which is a good starting point. The Virtual Memory Manager manages the physical memory used for the cache. The most important factor is if the file is still open by any running process.
Allocated pages stay in Virtual Memory for a while depending on multiple factors. The Windows Cache Manager uses Virtual Memory to store the cache pages one by one for each open file in block sizes of 256 kb. To understand what is going wrong you have to understand how the Windows Cache Manager works internally.
But it turned out this only fixed part of the underlying issue. To prevent the cache manager from using too much physical memory IBM uses the system call SetSystemFileCacheSize(.) (ref: ). Most of them have been already technoted and IBM has build work-arounds.įor example the problem with the large amount of memory used by the cache manager which competed with memory allocations by Domino. New Performance Problem with Domino on Windows 2008 64bit Daniel Nashed 1 October 2010 18:05:16 Since Domino is supported on Windows 64bit there have been a couple of issues in the performance area.