On 4/2/2015 2:23 PM, Upayavira wrote: > I think the point is more that the majority of developers use a Unix > based system, and the majority of testing is done on Unix based systems. > > Also, there are ways in which the Windows memory model differs from a > Unix one, meaning certain memory optimisations have not been possible > under Windows. A Lucene index is accessed via a Directory object, and > Solr/Lucene will, by default, choose one according to your architecture: > Windows/Unix, 32/64 bit, etc. 64 bit Unix gives you the best options. > > My unconfirmed understanding is that this is to do with the > MemoryMappedDirectory implementation which will only work on Unix. This > implementation uses the OS disk cache directly, rather than reading > files from the disk cache into the heap, and is therefore much more > efficient. I’m sure there are some folks here who can clarify if I got > my implementation names or other details wrong. > > So, Solr *will* run on Windows, whether desktop (for development) or > server. However, it is much less tested, and you will find some things, > such as new init scripts, and so on, that maybe have not yet been ported > over to Windows.
MMap seems to work perfectly fine on Windows. Uwe Schindler indicates that MMap is used by default on 64-bit Windows JVMs since Lucene/Solr 3.1: http://blog.thetaphi.de/2012/07/use-lucenes-mmapdirectory-on-64bit.html For various reasons, MMap being only one of them, Solr should always be run on 64-bit operating systems with a 64-bit Java. There are no major *disadvantages* to running Solr on Windows, as long as it's a 64-bit Server OS. NTFS cannot compare to the best filesystems on a recent Linux kernel, but it's not horrible. If you've sized your RAM appropriately, Solr will hardly ever hit the disk, so the filesystem may not make much difference. Thanks, Shawn