[
https://issues.apache.org/jira/browse/SOLR-10420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15955575#comment-15955575
]
Markus Jelsma commented on SOLR-10420:
--------------------------------------
So it seems. Forced GC does not remove the object instances in >= 6.1.0. In
6.0.x regular GC and forced GC does remove the instances from the object count.
I think almost everyone should be able to see it for themselves, almost all our
Solr instances show this problem immediately after restart, some don't in some
occasions.
Although they don't consume a lot of bytes, the problem appears to cause more
CPU time being used up.
Filtering the memory sampler for org.apache.solr.common reveals it right away.
> Solr 6.x leaking one SolrZkClient instance per second
> -----------------------------------------------------
>
> Key: SOLR-10420
> URL: https://issues.apache.org/jira/browse/SOLR-10420
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Affects Versions: 6.5, 6.4.2
> Reporter: Markus Jelsma
> Fix For: master (7.0), branch_6x
>
>
> One of our nodes became berzerk after a restart, Solr went completely nuts!
> So i opened VisualVM to keep an eye on it and spotted a different problem
> that occurs in all our Solr 6.4.2 and 6.5.0 nodes.
> It appears Solr is leaking one SolrZkClient instance per second via
> DistributedQueue$ChildWatcher. That one per second is quite accurate for all
> nodes, there are about the same amount of instances as there are seconds
> since Solr started. I know VisualVM's instance count includes
> objects-to-be-collected, the instance count does not drop after a forced
> garbed collection round.
> It doesn't matter how many cores or collections the nodes carry or how heavy
> traffic is.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
