I wanted to reply on this because it seems that a few people have had similar
problems and I am very pleased with the simple solution.
Basically I re-created the index using OMIT NORMS where ever possible, as well
as Field.Store.NO where ever possible. The result shrunk my index from 19GB to
4
Would it be fair to say that you can expect OutOfMemory errors if you run
complex queries? ie sorts, boosts, weights...
My query looks like this:
+(pathNodeId_2976569:1^5.0 pathNodeId_2976969:1 pathNodeId_2976255:1
pathNodeId_2976571:1) +(pathClassId:1 pathClassId:346 pathClassId:314) -id:369
les in one of the Windows system directories so it's possible
that you're hitting something in there even though you aren't trying
Kudos for writing that test program, by the way. It sure removed
a lot of variables from the situation.
Best
[EMAIL PROTECTED]
On 4/5/07, Craig W
ore stable than even 1.5.
Otis
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simpy -- http://www.simpy.com/ - Tag - Search - Share
----- Original Message
From: Craig W Conway <[EMAIL PROTECTED]>
To: java-user@lucene.apache.org
Sent: Wednesday, April 4, 2007 1:25:27 PM
Subject: How many Searches is
I am using an RMI architecture for calling a remote service which uses an
IndexSearcher in its own JVM. I am starting the service with the following
provisions for memory allocation and garbage collection: java -server -Xmx1024m
-XX:+UseConcMarkSweepGC -XX:+UseParNewGC
After about 1000 search c
