used the Collections API and two cores mysteriously
failed to reload that would be a bug. Assuming the replicas in
question
were up and running at the time you reloaded.
Thanks for letting us know what's going on.
Erick
On Tue, Mar 10, 2015 at 4:34 AM, Martin de Vries
mar...@downnotifier.com
don't
have the JIRA numbers right off.
Best,
Erick
On Thu, Mar 5, 2015 at 4:46 PM, Shawn Heisey apa...@elyograg.org
wrote:
On 3/5/2015 3:13 PM, Martin de Vries wrote:
I understand there is not a master in SolrCloud. In our case we
use
haproxy as a load balancer for every request. So when
commits that happen may very
well be slightly out of sync, the index size, number of segments,
generations, and all that are pretty safely ignored.
Best,
Erick
On Thu, Mar 5, 2015 at 6:50 AM, Martin de Vries
mar...@downnotifier.com
wrote:
Hi Andrew, Even our master index is corrupt, so I'm
Hi,
We have index corruption on some cores on our Solrcloud running version
4.8.1. The index is corrupt on several servers. (for example: when we do
an fq search we get results on some servers, on other servers we don't,
while the stored document contains the field on all servers).
A full
Hi Andrew,
Even our master index is corrupt, so I'm afraid this won't help in our
case.
Martin
Andrew Butkus schreef op 05.03.2015 16:45:
Force a fetchindex on slave from master command:
http://slave_host:port/solr/replication?command=fetchindex - from
Hi,
I have two questions about upgrading Solr:
- We upgrade Solr often, to match the latest version. We have a number
of servers in a Solrcloud and prefer to upgrade one or two servers first
and upgrade the other server a few weeks later when we are sure
everything is stable. Is this the
We are running stable now for a full day, so the bug has been fixed.
Many thanks!
Martin
Martin, I’ve committed the SOLR-5875 fix, including to the
lucene_solr_4_7 branch.
Any chance you could test the fix?
Hi Steve,
I'm very happy you found the bug. We are running the version from SVN
on one server and it's already running fine for 5 hours. If it's still
stable tomorrow than
Hi,
When our server crashes the memory fills up fast. So I think it might
be a specific query that causes our servers to crash. I think the query
won't be logged because it doesn't finish. Is there anything we can do
to see the currently running queries in de Solr server (so when can see
We parsed the Unreachable Objects of the memory dump.
The memory leak seems to be in:
org.apache.solr.handler.component.ShardFieldSortedHitQueue
https://www.dropbox.com/s/hdv49xlb4g4wi03/Screenshot%202014-03-07%2016.51.56.png
Martin
IndexSchema is using 62% of the memory
That seems odd. Can you see what objects are taking all the RAM in
the
IndexSchema?
We investigated this and found out that a dictionary was loaded for
each core, taking loads of memory. We the the config to
shareSchema=true. The memory usage
The memory leak seems to be in:
org.apache.solr.handler.component.ShardFieldSortedHitQueue
I think our issue might be related to this one, because this change has
been introduced in 4.7 and has changes to ShardFieldSortedHitQueue:
https://issues.apache.org/jira/browse/SOLR-5354
Is the
Hi,
We have 5 Solr servers in a Cloud with about 70 cores and 12GB
indexes in total (every core has 2 shards, so it's 6 GB per server).
After upgrade to Solr 4.7 the Solr servers are crashing constantly
(each server about one time per hour). We currently don't have any clue
about the
garbage collector and the regular one, the problem happens
with both of them.
We use Java 1.6 on some servers. Will Java 1.7 be
better?
Martin
Martin de Vries schreef op 12.11.2013 10:45:
Hi,
We have:
Solr 4.5.1 - 5 servers
36 cores, 2 shards each,
2 servers per shard (every core
Hi,
We have:
Solr 4.5.1 - 5 servers
36 cores, 2 shards each, 2 servers per shard (every core is on 4
servers)
about 4.5 GB total data on disk per server
4GB JVM-Memory per server, 3GB average in use
Zookeeper 3.3.5 - 3 servers (one shared with Solr)
haproxy load balancing
Our Solrcloud is
15 matches
Mail list logo
