sure, SSD or RAM disks fix these problems with IO.
Anyhow, I can really see no alternative for some in memory index for
slaves, especially for low latency master-slave apps (high commit rate
is a problem).
having possibility to run slaves in memory that are slurping updates
from Master seams t
sure, SSD or RAM disks fix these problems with IO.
Anyhow, I can really see no alternative for some in memory index for
slaves, especially for low latency master-slave apps (high commit rate
is a problem).
having possibility to run slaves in memory that are slurping updates
from Master seams t
On Wed, 2011-06-29 at 09:35 +0200, eks dev wrote:
> In MMAP, you need to have really smart warm up (MMAP) to beat IO
> quirks, for RAMDir you need to tune gc(), choose your poison :)
Other alternatives are operating system RAM disks (avoids the GC
problem) and using SSDs (nearly the same performa
...Using RAMDirectory really does not help performance...
I kind of agree, but in my experience with lucene, there are cases
where RAMDirectory helps a lot, with all its drawbacks (huge heap and
gc() tuning).
We had very good experience with MMAP on average, but moving to
RAMDirectory with prop
Using RAMDirectory really does not help performance. Java garbage
collection has to work around all of the memory taken by the segments.
It works out that Solr works better (for most indexes) without using
the RAMDirectory.
On Sun, Jun 26, 2011 at 2:07 PM, nipunb wrote:
> PS: Sorry if this is a
Thanks for the pointer to MMapDirectoryFactory.
Not having replication with RAMDirectoryFactory is a deal killer. We dont
want to index on the machines that serve queries.
>From what I can gather from reading, MMapDirectory + SSD could be a happy
medium.
I'll try to evaluate these a bit more form
Your best bet is MMapDirectoryFactory, you can come very close to the
performance of the RAMDirectory. Unfortunatelly this setup with
Master_on_disk->Slaves_in_ram type of setup is not possible using
solr.
We are moving our architecture to solr at the moment, and this is one
of "missings" we have
On Mon, Jun 27, 2011 at 12:49 PM, nipunb wrote:
> I found a similar post -
> http://lucene.472066.n3.nabble.com/Problems-with-RAMDirectory-in-Solr-td1575223.html
> It mentions that Java based replication might work (This is what I have
> used, but didn't work for me)
Solr Replication does not wor
I found a similar post -
http://lucene.472066.n3.nabble.com/Problems-with-RAMDirectory-in-Solr-td1575223.html
It mentions that Java based replication might work (This is what I have
used, but didn't work for me)
More interestingly it points out that OS's file system cache maybe able to
do this job
