Thanks all who replied, lots of information to help us improve our use and
management of Solr!
>
> On 15 February 2017 at 08:04 Michael Kuhlmann wrote:
>
>
> The number of cores is not *that much* important compared to the index
> size, but each core has its memory overhead. For in
The number of cores is not *that much* important compared to the index
size, but each core has its memory overhead. For instance, caches are
based on cores, so you're having 36 individual caches per type.
Best,
Michael
Am 14.02.2017 um 16:39 schrieb Leon STRINGER:
>> On 14 February 2017 at 14
Yeah, 512M is the default if for Java, but Solr _really_ likes memory.
These two lines are "smoking guns"
Max heap after conc GC: 488.7M (99.6%)
Max heap after full GC: 490M (99.9%)
So what's happening (I think) is that you're spending a lot of cycles
recovering a very little bit of memory and th
>
> On 14 February 2017 at 15:49 Walter Underwood
> wrote:
>
>
> Yes, 512 MB is far too small. I’m surprised it even starts. We run with 8
> Gb.
>
Thanks, in fairness 512 MB was the default and we're new to this. We'll look at
what we're allocating to Solr to tune this.
>
> wund
Yes, 512 MB is far too small. I’m surprised it even starts. We run with 8 Gb.
wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/ (my blog)
> On Feb 14, 2017, at 7:39 AM, Leon STRINGER wrote:
>
>>
>>On 14 February 2017 at 14:44 Michael Kuhlmann wrote:
>>
>>
>
>
> On 14 February 2017 at 14:44 Michael Kuhlmann wrote:
>
>
> Wow, running 36 cores with only half a gigabyte of heap memory is
> *really* optimistic!
>
> I'd raise the heap size to some gigabytes at least and see how it's
> working then.
>
I'll try increasing the heap s
Wow, running 36 cores with only half a gigabyte of heap memory is
*really* optimistic!
I'd raise the heap size to some gigabytes at least and see how it's
working then.
-Michael
Am 14.02.2017 um 15:23 schrieb Leon STRINGER:
> Further background on the environment:
>
> There are 36 cores, with a
Further background on the environment:
There are 36 cores, with a total size of 131 MB (based on the size reported by
"Master (Searching)" in the web console).
The Java memory parameters in use are: -Xms512m -Xmx512m.
>
> On 14 February 2017 at 05:45 Erick Erickson
> wrote:
>
> GCView
Why is this a problem? CPU load and log file size.
The CPU load reported by top increases from it's normal 0-1% resting state to
25-50% continually, and higher when searching, indexing, etc.
With 6.1.0 we just got a huge GC log file. With 6.4.1 the GC log is now cycled
before it grows too large,
Why is this a problem? Are you seeing unacceptable slowness?
It's fairly common for Java to frequently do GC, the problem happens
when it uses stop-the-world GC. So unless you're seeing visibly
slow performance I'd say ignore it.
Curiously, increasing the Java heap a little bit sometimes helps
as
Hi,
I get an issue where, when I'm deleting and adding Solr cores, it appears to go
into a loop increasing CPU load and continually (every 2 seconds) logging to the
garbage collection log.
I had this problem with 6.1.0 so we've just upgraded to 6.4.1 and the issue
still occurs. The entries being
11 matches
Mail list logo
