Sounds like you may need to have some sort of distributed system, I just wanted to make sure you were aware of the cost/benifits of just buying a big 62bit/8Gb ram machine, vs having to not only maintain and power several 32 bit machines, but also maintain and support your now more complicated code.

I have seen it too many times developers/companies spend so much money in not just the initial development, but long term support and maintenance that could have been simplified by just buying a bigger/ better more powerful machine in the first place.

I am interested to see what other people have to say about how to solve your problem.

Best regards,
Jacob

On 16/11/2009, at 3:39 PM, Wenbo Zhao wrote:

My data is categorized by date. About 14M+ docs per month, 37M+ terms.
When I use 1G heap size to do search of 10 month index, I got OOM.
The problem is I can't increase heap size in an easy way.
I have several machines, all 32bit windows, 4G ram.
And my goal is to index 10 year's data, plus more data every day !
If I put all of them together, I will need 8G+ ram to run search.
Maybe another 8G+ ram to run indexwriter.

I think to split large index into smaller indexes and use a group of
machines to work as one is more flexible and faster compare to one
huge ram machine.
Any suggestions ?  beside more rams.


2009/11/16 Jacob Rhoden <jrho...@unimelb.edu.au>:
Not sure how large your index is, but it might be easier (if possible to increase your memory) than to develop a fairly complicated alternative
strategy.

On 16/11/2009, at 2:12 PM, Wenbo Zhao wrote:

Hi, all
I'm facing a large index, on a x86 win platform which may not have big
enough jvm heap space to hold the entire index.
So, I think it's possible to split the index into several smaller
indexes, run them in different jvm instances on different machine.
Then for each query, I can concurrently run it one every indexes and
merge the result together.
This can be a workaround of OutOfMemory issue.
But before I start to do this, I want to ask if Lucene already have a
solution for things like this.
Thanks.

--

Best Regards,
ZHAO, Wenbo

=======================

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org


____________________________________
Information Technology Services,
The University of Melbourne

Email: jrho...@unimelb.edu.au
Phone: +61 3 8344 2884
Mobile: +61 4 1095 7575


---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org





--

Best Regards,
ZHAO, Wenbo

=======================

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org


____________________________________
Information Technology Services,
The University of Melbourne

Email: jrho...@unimelb.edu.au
Phone: +61 3 8344 2884
Mobile: +61 4 1095 7575


---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org

Reply via email to