On 4/18/2019 1:00 AM, vishal patel wrote:
Thanks for your reply.
You are right. I checked GC log and use of GC Viewer I noticed that pause time
was 111.4546597 secs.
<snip>
2019-04-08T13:52:09.939+0100: 796800.430: [GC (Allocation Failure) 796800.431:
[ParNew
Desired survivor size 2415919104 bytes, new threshold 8 (max 8)
- age 1: 197413992 bytes, 197413992 total
- age 2: 170743472 bytes, 368157464 total
- age 3: 218531128 bytes, 586688592 total
- age 4: 3636992 bytes, 590325584 total
- age 5: 18608784 bytes, 608934368 total
- age 6: 163869560 bytes, 772803928 total
- age 7: 55349616 bytes, 828153544 total
- age 8: 5124472 bytes, 833278016 total
: 11580169K->985493K(13107200K), 111.4543849 secs]
39847019K->29253720K(60293120K), 111.4546597 secs] [Times: user=302.38 sys=109.81,
real=111.46 secs]
From another log entry that you sent I can see that your heap size is
over 50 GB. This is a really really big heap, and the log entry I
included above is probably a full GC. The GC config that Solr ships
with will try to avoid full GCs ... but if the heap is too small for
what Solr is being asked to do, then they will not be possible to avoid.
Which I think might be what is happening here.
In this case, it's probably preferable to figure out why the heap has to
be so big and fix that rather than increase the heap size ... but
increasing the heap size might also help, assuming you have any memory
left on the server.
Can you tell me how many documents are being handled by this Solr
instance? This will be gotten by finding the maxDoc count from all
cores and adding those numbers together.
Can you gather and share the screenshot described on the following wiki
page?
https://wiki.apache.org/solr/SolrPerformanceProblems#Asking_for_help_on_a_memory.2Fperformance_issue
I would also like to see the solrconfig.xml from at least one of the
large indexes.
May I set any max timeout when GC pause 2 second in Solr.xml or any file of Zoo
keeper ? what to do when GC pause time more?
A GC pause lasting 111 seconds is an indication of a problem that you
can't fix with increased timeouts.
Thanks,
Shawn
