On 11/4/2012 11:41 PM, deniz wrote:
Michael Della Bitta-2 wrote
No, RAMDirectory doesn't work for replication. Use MMapDirectory... it
ends up storing the index in RAM and more efficiently so, plus it's
backed by disk.
Just be sure to not set a big heap because MMapDirectory works outside of
heap.
for my tests, i dont think index is ended up in ram with mmap... i gave
4gigs for heap while using mmap and got mapping error while indexing...
while index should be something around 2 gigs, ram consumption was around
300mbs...
With mmap, the ram is not actually "consumed" by your application, which
in this case is Java. The operating system is handling it --
transparently mapping the files on disk to a virtual memory space and
using excess RAM to cache that data and make it fast. If you have
enough extra memory (disk cache) to fit the entire index, the OS will
never have to read any part of the index from disk more than once. With
RAMDirectory, the index has to go into the Java heap, which is much less
efficient at memory management than the native operating system.
Can anyone explain why RAMDirectory cant be used for replication? I cant see
why the master is set for using RAMDirectory and replica is using MMap or
some other? As far as I understand SolrCloud is some kinda pushing from
master to replica/slave... so why it is not possible to push from RAM to
HDD? If my logic is wrong, someone can please explain me all these?
With RAMDirectory, there are no files to copy. Replication does not
copy Solr (Lucene) documents, it copies files.
Thanks,
Shawn
