Right, I've seen situation where as Solr is using a high percentage of the
available memory, Java spends more and more time in GC cycles. Say
you've allocated 8G to the heap. Say further that the "steady state" for
Solr needs 7.5g (numbers made up...). Now the GC algorithm only has
0.5G to play with and it spends a lot of time compacting that 0.05G.

But, if you increase the heap to, say, 12G, the background GC threads
have much greater opportunities to collect unused memory without
interrupting normal Solr processing....


So as Michael says, bumping the -Xmx up may alleviate the problem
entirely.

Best,
Erick

On Thu, Dec 18, 2014 at 4:50 PM, Michael Della Bitta
<michael.della.bi...@appinions.com> wrote:
> I've been experiencing this problem. Running VisualVM on my instances shows
> that they spend a lot of time creating WeakReferences
> (org.apache.lucene.util.WeakIdentityMap$IdentityWeakReference that is). I
> think what's happening here is the heap's not big enough for Lucene's caches
> and it ends up thrashing.
>
> You might try bumping up your heap some to see if that helps. It's made a
> difference for me, but mostly in delaying the onset and limiting the
> occurrence of this. Likely I just need an even larger heap.
>
> Michael
>
>
>
> On 12/18/14 17:36, heaven wrote:
>>
>> Hi,
>>
>> We have 2 shards, each one has 2 replicas and each Solr instance has a
>> single thread that constantly uses 100% of CPU:
>> <http://lucene.472066.n3.nabble.com/file/n4175088/Screenshot_896.png>
>>
>> After restart it is running normally for some time (approximately until
>> Solr
>> comes close to Xmx limit), then the mentioned thread start consuming one
>> CPU. 4 solr instances = minus 4 CPU cores.
>>
>> We do not commit manually and the search is not used too intensively.
>>
>> {code}
>> <autoCommit>
>>    <maxDocs>25000</maxDocs>
>>    <maxTime>300000</maxTime>
>>    <openSearcher>false</openSearcher>
>> </autoCommit>
>>
>> <autoSoftCommit>
>>    <maxTime>15000</maxTime>
>> </autoSoftCommit>
>> {code}
>>
>> So I was wondering if that's correct, if this is supposed to be or if
>> something is wrong with our configuration or with Solr.
>>
>> Thanks,
>> Alex
>>
>>
>>
>> --
>> View this message in context:
>> http://lucene.472066.n3.nabble.com/Endless-100-CPU-usage-on-searcherExecutor-thread-tp4175088.html
>> Sent from the Solr - User mailing list archive at Nabble.com.
>
>

Reply via email to