lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jian chen <chenjian1...@gmail.com>
Subject Re: java on 64 bits
Date Fri, 21 Oct 2005 14:17:22 GMT
Hi,

Also, I think you may try to increase the indexInterval, it is set to 128,
but getting it larger, the .tii files will be smaller. Since .tii files are
loaded into memory as a whole, so, your memory usage might be smaller.
However, this change might affect your search speed. So, be careful about
the value you want to set, not too high though.

Just my thoughts, hope helps.

Jian

On 10/21/05, Aigner, Thomas <TAigner@wescodist.com> wrote:
>
> I have seen quite a few posts on using the 1.9 dev version for
> production uses. How stable is it? Is it really ready for production?
> I would like to use it.. but I never ever put beta packages in
> procution.. but then again.. I'm always dealing with Microsoft :)
>
> Tom
>
> -----Original Message-----
> From: Yonik Seeley [mailto:yseeley@gmail.com]
> Sent: Friday, October 21, 2005 9:28 AM
> To: java-user@lucene.apache.org
> Subject: Re: java on 64 bits
>
> 1) make sure the failure was due to an OutOfMemory exception and not
> something else.
> 2) if you have enough memory, increase the max JVM heap size (-Xmx)
> 3) if you don't need more than 1.5G or so of heap, use the 32 bit JVM
> instead (depending on architecture, it can acutally be a little faster
> because more references fit in the CPU cache).
> 4) see how many indexed fields you have and if you can consolidate any
> of
> them
> 4.5) if you don't have too many indexed fields, and have enough spare
> file
> descriptors, try using the non-compound file format instead.
> 5) run with the latest version of lucene (1.9 dev version) which may
> have
> better memory usage during optimizes & segment merges.
> 6) If/when optional norms
> http://issues.apache.org/jira/browse/LUCENE-448
> makes it into lucene, you can apply it to any indexed fields for which
> you
> don't need index-time boosting or length normalization.
>
> As for getting rid of your current intermediate files, I'd rebuild from
> scratch just to ensure things are OK.
>
> -Yonik
> Now hiring -- http://tinyurl.com/7m67g
>
> On 10/21/05, Roxana Angheluta <roxana@attentio.com> wrote:
> >
> > Thank you, Yonik, it seems this is the case.
> > What can we do in this case? Would running the program with java -d32
> be
> > a solution?
> >
> > Thanks again,
> > roxana
> > >One possibility: if lucene runs out of memory while adding or
> optimizing,
> > it
> > >can leave unused files beind that increase the size of the index. A
> 64
> > bit
> > >JVM will require more memory than a 32 bit one due to the size of all
> > >references being doubled.
> > >
> > >If you are using the compound file format (the default - check for
> .cfs
> > >files), then it's easy to check if you have this problem by seeing if
> > there
> > >are any *.f* files in the index directory. These are intermediate
> files
> > and
> > >shouldn't exist for long in a compound-file index.
> > >
> > >-Yonik
> > >Now hiring -- http://tinyurl.com/7m67g
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message