Not sure if this would help you, but we encountered java heap OOM issues with 1.1 earlier this year. We patched solr with the latest bits at the time, which included a lucene memory fix for java heap OOM issues. ( http://issues.apache.org/jira/browse/LUCENE-754)
Different servlet container (Tomcat 5.5) and we're running JRE 5 v9. After applying the update to the solr bits that included the patch mentioned above, OOM has never re-appeared. -- j On 7/30/07, Mike Klaas <[EMAIL PROTECTED]> wrote: > > On 30-Jul-07, at 11:35 AM, David Whalen wrote: > > > Hi Yonik! > > > > I'm glad to finally get to talk to you. We're all very impressed > > with solr and when it's running it's really great. > > > > We increased the heap size to 1500M and that didn't seem to help. > > In fact, the crashes seem to occur more now than ever. We're > > constantly restarting solr just to get a response. > > How much memory is on the system, and is anything else running? How > large is the resulting index? > > If you're willing for some queries to take longer after a commit, > reducing/eliminating the autoWarmCount for your queryCache and > facetCache should decrease the peak memory usage (as Solr as two > copies of the cache open at that point). Setting it to zero could up > the halve the peak memory usage (at the cost of loss of performance > after commits). > > As yonik suggested, check for PERFORMANCE warnings too--you may have > more than two Searchers open at once. > > -Mike > > >
