Re: Help optimizing

2008-05-06 Thread Otis Gospodnetic
filtering): "milk", "with", "honey", "is", "god" Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch - Original Message > From: Daniel Andersson <[EMAIL PROTECTED]> > To: solr-user@lucene.apache.or

Re: Help optimizing

2008-05-06 Thread Otis Gospodnetic
May 6, 2008 6:01:01 PM > Subject: Re: Help optimizing > > > On May 6, 2008, at 2:19 PM, Grant Ingersoll wrote: > > > On May 3, 2008, at 1:06 PM, Daniel Andersson wrote: > > > >> When performing a search, the results vary between 1.5 seconds up > >> t

RE: Help optimizing

2008-05-06 Thread Lance Norskog
To: solr-user@lucene.apache.org Subject: Re: Help optimizing Thanks Otis! On May 4, 2008, at 4:32 AM, Otis Gospodnetic wrote: > You have a lot of fields of type text, but a number of field sound > like they really need not be tokenized and should thus be of type > string. I've

Re: Help optimizing

2008-05-06 Thread Daniel Andersson
On May 6, 2008, at 7:26 PM, Lance Norskog wrote: One cause of out-of-memory is multiple simultaneous requests. If you limit the query stream to one or two simultaneous requests, you might fix this. No, Solr does not have an option for this. The servlet containers have controls for this that

Re: Help optimizing

2008-05-06 Thread Daniel Andersson
On May 6, 2008, at 2:19 PM, Grant Ingersoll wrote: On May 3, 2008, at 1:06 PM, Daniel Andersson wrote: When performing a search, the results vary between 1.5 seconds up to 60 seconds. Is this pure Solr time or overall application time? I ask, b/c it is often the case that people are mea

Re: Help optimizing

2008-05-06 Thread Daniel Andersson
On May 6, 2008, at 4:00 AM, Mike Klaas wrote: On 3-May-08, at 10:06 AM, Daniel Andersson wrote: How do I optimize Solr to better use all the RAM? I'm using java6, 64bit version, and start Solr using: java -Xmx7500M -Xms4096M -jar start.jar But according to top it only seems to be using 7.

Re: Help optimizing

2008-05-06 Thread Daniel Andersson
Thanks Otis! On May 4, 2008, at 4:32 AM, Otis Gospodnetic wrote: You have a lot of fields of type text, but a number of field sound like they really need not be tokenized and should thus be of type string. I've changed quite a few of them over to string. Still not sure about the differe

Re: Help optimizing

2008-05-06 Thread Otis Gospodnetic
ene - Solr - Nutch - Original Message > From: Lance Norskog <[EMAIL PROTECTED]> > To: solr-user@lucene.apache.org > Cc: "Norskog, Lance" <[EMAIL PROTECTED]> > Sent: Tuesday, May 6, 2008 1:26:28 PM > Subject: RE: Help optimizing > > One cause o

RE: Help optimizing

2008-05-06 Thread Lance Norskog
-Original Message- From: Grant Ingersoll [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 06, 2008 5:19 AM To: solr-user@lucene.apache.org Subject: Re: Help optimizing On May 3, 2008, at 1:06 PM, Daniel Andersson wrote: > Hi (again) people > > We've now invested in a server wi

Re: Help optimizing

2008-05-06 Thread Grant Ingersoll
On May 3, 2008, at 1:06 PM, Daniel Andersson wrote: Hi (again) people We've now invested in a server with 8 GB of RAM after too many OutOfMemory-errors. Our database/index is 3.5 GB and contains 4,352,471 documents. Most documents are less than 1 kb. When performing a search, the results

Re: Help optimizing

2008-05-05 Thread Mike Klaas
On 3-May-08, at 10:06 AM, Daniel Andersson wrote: Our database/index is 3.5 GB and contains 4,352,471 documents. Most documents are less than 1 kb. When performing a search, the results vary between 1.5 seconds up to 60 seconds. I don't have a big problem with 1.5 seconds (even though belo

Re: Help optimizing

2008-05-03 Thread Otis Gospodnetic
s with jConsole? Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch - Original Message > From: Daniel Andersson <[EMAIL PROTECTED]> > To: solr-user@lucene.apache.org > Sent: Saturday, May 3, 2008 7:06:10 PM > Subject: Help optimizing > > Hi (again)

Help optimizing

2008-05-03 Thread Daniel Andersson
Hi (again) people We've now invested in a server with 8 GB of RAM after too many OutOfMemory-errors. Our database/index is 3.5 GB and contains 4,352,471 documents. Most documents are less than 1 kb. When performing a search, the results vary between 1.5 seconds up to 60 seconds. I don't