There is no persistency with in memory indices and local gateway, only with
shared gateway. Are you sure you got results? Also, did you do a full
cluster shutdown (if you are running more than one node)?
Note, there are bugs in the in memory (outside of JVM heap) store which I
did not manage yet to track down. Use the file system ones, or mmapfs, it
should be fast enough. If not, you can set the store to "ram" which defaults
to Lucene in memory (in heap) memory store.
On Fri, Sep 16, 2011 at 11:36 AM, Karussell firstname.lastname@example.org:
in-memory means that ES will nevertheless makes backup (via local
gateway) of the data to recover from that in a case of an incident.
But if the data does not fit completely into memory ES will throw at
some point OutOfMem errors. No 'transition' is done.
What you probably want is the default disc base index, which is also
in-memory for parts of the data (ES does a lot caching but also the
Operating system) and so it'll require less RAM and reads from disc if
the data is not cached
On 16 Sep., 03:41, rcch vijay....@gmail.com wrote:
- I set up an index with -Des.index.storage.type=memory.
- I added a bunch of documents.
- Then, I killed elastic search
- I brought it back up and queried the index - and the searches were
I believe there's a gap in my understanding. If the index is an in-
memory index - I thought there is no persistence in this case. But
seems like there is a built in layer of persistence. I use the default
configuration (did not set up a gateway, etc).
So the questions are:
Is there persistence for in-memory indices ? If not, how did my
example work ?
What happens if I go over the index limit for an in-memory index ?
Will ES gracefully transition between keeping things in RAM and going
to diske or will it die ?
How do I set up a hybrid where I keep a considerable amount of
stuff in RAM (cached) and go to diske when needed?
Thank you for your help.