ng I am missing here? is there an option to disable the disk space
check that I need to pass? I can't find anything in the documentation at this
point.
[https://storage.googleapis.com/e24-email-images/e24logonotag.png]<https://www.evolve24.com>
Andrew Kettmann
DevOps Engineer
P: 1.314.
is that
at least.
From: Andrew Kettmann
Sent: Tuesday, June 18, 2019 11:32:43 AM
To: solr-user@lucene.apache.org
Subject: Solr 7.7.2 - SolrCloud - SPLITSHARD - Using LINK method fails on disk
usage checks
Using Solr 7.7.2 Docker image, testing some of the new
d the ephemeralOwner of the parent leader node
### END
________
From: Andrew Kettmann
Sent: Tuesday, June 18, 2019 3:05:15 PM
To: solr-user@lucene.apache.org
Subject: Re: Solr 7.7.2 - SolrCloud - SPLITSHARD - Using LINK method fails on
disk usage checks
Looks like the di
s on
disk usage checks
Hi Andrew,
Please create a JIRA issue and attach this patch, I’ll look into fixing this.
Thanks!
> On 18 Jun 2019, at 23:19, Andrew Kettmann
> wrote:
>
> Attached the patch, but that isn't sent out on the mailing list, my mistake.
> Patch below:
&g
'bytes=9708660}',
'event.properties.belowSize': '{}',
'event.properties.requestedOps': '[Op{action=SPLITSHARD, '
'hints={COLL_SHARD=[{\n'
' "
error. Which what I expected was the
collection creation to fail. This is the behavior I had seen in the past, but
after tearing down and recreating the cluster in a higher environment, it does
not appear to function.
Is there some prerequisite before policies will be respected? The .system
collection
Is there some step I am missing here? Policies seem to be entirely ignored in
this new cluster and I am at a loss. Is there some default setting that will
cause autoscaling to be ignored?
From: Andrew Kettmann
Sent: Tuesday, June 25, 2019 1:04:21 PM
To: solr
be
unable to be strict on their own it appears.
Hopefully this can solve some issues for other people as well.
From: Andrew Kettmann
Sent: Tuesday, June 25, 2019 1:04:21 PM
To: solr-user@lucene.apache.org
Subject: Solr 7.7.2 - Autoscaling in new cluster ignoring s
T=foo, then it will fail if it
> cannot satisfy another strict rule. So sysprop autoscaling rules appear to be
> unable to be strict on their own it appears.
>
>
> Hopefully this can solve some issues for other people as well.
>
>
> From:
like to avoid that if
possible, but also creating a collection in sub 10 minutes would be neat too.
I appreciate any input/suggestions anyone has!
[https://storage.googleapis.com/e24-email-images/e24logonotag.png]<https://www.evolve24.com>
Andrew Kettmann
DevOps Engineer
P: 1.314.59
> How many zookeepers do you have? How many collections? What is there size?
> How much CPU / memory do you give per container? How much heap in comparison
> to total memory of the container ?
3 Zookeepers.
733 containers/nodes
735 total cores. Each core ranges from ~4-10GB of index. (Autoscaling
> You’re going to want to start by having more than 3gb for memory in my
> opinion but the rest of your set up is more complex than I’ve dealt with.
right now the overseer is set to a max heap of 3GB, but is only using ~260MB of
heap, so memory doesn't seem to be the issue unless there is a par
"<2",
"node":"#ANY",
"strict":"false"}]
On Wed, Sep 4, 2019 at 1:49 AM Andrew Kettmann
wrote:
>
> Currently our 7.7.2 cluster has ~600 hosts and each collection is using an
> autoscaling policy based on system
13 matches
Mail list logo
