Heap: start small and increase as necessary. Leave as much RAM for FS cache, don't give it to the JVM until it starts crying. SPM for Solr will help you see when Solr and JVM are starting to hurt.
Otis > On Jul 12, 2016, at 11:45, Jason <hialo...@gmail.com> wrote: > > I'm using optimize because it's a option for fast search. > Our index updates one or more weekly. > If I don't use optimize, many index files should be kept. > Any performance issues in that case? > > And I'm wondering relation between index file size and heap size. > In case of running as master server that only update index, > is there any guide for heap size include Xmx, NewSize, MaxNewSize, etc.? > > > > Yonik Seeley wrote >> Optimize is a very expensive operation. It involves reading the >> entire index and merging and rewriting at a single segment. >> If you find it too expensive, do it less often, or don't do it at all. >> It's an optional operation. >> >> -Yonik >> >> >> On Mon, Jul 11, 2016 at 10:19 PM, Jason < > >> hialooha@ > >> > wrote: >>> hi, all. >>> >>> I'm running solr instance with two cores and JVM max heap is 32G. >>> Each core index size is 68G, 61G repectively. >>> I'm always keeping on optimization after update index. >>> BTW, on last week, document update is completed but optimize phase cpu is >>> very high. >>> I think that is because long gc time. >>> How should I solve this problem? >>> welcome any idea. >>> thanks, >>> >>> >>> >>> -- >>> View this message in context: >>> http://lucene.472066.n3.nabble.com/High-cpu-and-gc-time-when-performing-optimization-tp4286704.html >>> Sent from the Solr - User mailing list archive at Nabble.com. > > > > > > -- > View this message in context: > http://lucene.472066.n3.nabble.com/High-cpu-and-gc-time-when-performing-optimization-tp4286704p4286796.html > Sent from the Solr - User mailing list archive at Nabble.com.
