Andrei, This is interesting. I have not observed this behavior on 2008 R2 and we cache quite a bit in memory (filters, field cache), but we're using local disk as opposed to an iSCSI SAN. Could there be some change that affects how those files are cached as opposed to local disk?
Michael -----Original Message----- From: Andrei Alecu [mailto:and...@tachyon-labs.com] Sent: Thursday, February 18, 2010 3:25 AM To: lucene-net-...@incubator.apache.org Subject: Lucene + Windows 2008 R2 performance issues It seems like Microsoft changed the way the memory manager works in the new Windows 7 kernel (which is what Windows 2008 R2 uses), not letting the system cache grows to use up all available RAM any more. (at least not in a predictable manner) Here's a reference: http://support.microsoft.com/kb/976618 "The memory management algorithms were updated to address this problem in Windows 7 and Windows Server 2008 R2 operating systems. Therefore, we do not recommend that you use the provided functions or the Microsoft Windows Dynamic Cache Service in computers that are running Windows 7 or Windows Server 2008 R2." This is in some circumstances a good thing, but it also means that things like Lucene now need to access the hard drive more than before. We're storing a lucene index on an iSCSI SAN, which used to work great pre W2K8 R2 because it eventually found its way into the system cache, and it wouldn't hit the network any more. This doesn't happen any more with R2 and we see some query time degradation. The solution to this issue would be to use Memory Mapped I/O, but I see that MMapDirectory is not implemented, are there any plans to implement it? There is first class support for Memory Mapped Files in .NET 4.0 which is still some time away, but until then the Win32 API could be used.
