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

Reply via email to