Thank you for the replies!
Because of everyone's insight, I was able to deduce that the problem was on
our configuration.
Our heap size was 10 gigs so I don't think this is the problem since we only
have 900k data. So when we took a closer look at our schema, 2 of the
relevant fields has ShingleF
So whenever we have long q values (from a sentence to a small paragraph), we
encounter some heap problems (OOM) and I guess this is normal?
So my question would be is how should we handle this type of problem? Of
course we could always limit the size of the search term queries in the
application s
So we are having some production issues with solr 6.6 with OpenJDK 11. There
are a lot of heap errors (ours was set to 10gig on a 16 gig instance) and we
never encountered this until we upgraded from Oracle JDK 8 to OpenJDK 11.
So is it advisable to keep it at openjdk 11 or should we downgrade to
Oh ok then that must no be the culprit then.
I got this logs from our application server but I'm not sure if this is
useful:
Caused by: org.apache.solr.client.solrj.SolrServerException:
org.apache.http.ParseException: Invalid content type:
at
org.apache.solr.client.solrj.impl.LBHttpSolrS
I know this is too late of a reply but I found this on our solr.log
java.nio.file.NoSuchFileException:
/opt/solr/server/solr/primaryCollectionPERF_shard1_replica9/data/index/segments_78
at
java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
at
java.base
I know this is too late of a reply but I found this on our solr.log
java.nio.file.NoSuchFileException:
/opt/solr/server/solr/primaryCollectionPERF_shard1_replica9/data/index/segments_78
at
java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
at
java.base
So I'm really liking the json facets in terms of performance and features but
I have the following questions:
- Can we use solr 7.6's facet.matches?
- Is there a way to only return the matched values in the facet? (we are
having problems with multivalued fields)
- Do we have any way to filter the
Thank you all for the kind and timely reply.
So what we did is we upgraded the instances to 16 gigs and we rarely
encounter this now.
So what we did was to increase the batch size to 500 instead of 50 and it
worked for our test data. But when we tried 1000 batch size, the invalid
content type err
So we have a dockerized aws environment with the solr docker container having
only 4 gigs for max ram.
Our problem is whenever we index, the container containing the leader shard
will restart after around 2 or less minutes of index time (batch is 50 docs
per batch with 3 threads in our app thread
We are having problems with zk / solr node recovery and we are encountering
this issue:
[ ] o.a.z.ClientCnxn Client session timed out, have not heard from server
in 5003ms
We have set the solr.xml zkClientTimeout to 30 secs.
What are we missing here?
--
Sent from: http://lucene.472066.n3.
Thank you very much!
This helped a lot in our estimates.
One last thing though, will a queue based system work for us? Or are there
better suitable implementations?
--
Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html
Thanks for the tip.
Although we have increased our application's heap to 4g and it is still not
enough.
I guess here are the things we think we did wrong:
- Each SP call will return 15 result sets.
- Each document can contain 300-1000 child documents.
- If the batch size is 1000, the child docum
1. We have 5 nodes and 3 zookeepers (will autoscale if needed)
2. We use java with the help of solrj / spring data for indexing.
3. We see the exception in our application so this is probably our fault and
not solr's so I'm asking what is the best approach for documents with a lot
of child docume
We are currently having problems in out current production setup in solr.
What we currently have is something like this:
- Solr 6.6.3 (cloud mode)
- 10 threads for indexing
- 900k total documents
- 500 documents per batch
So in each thread, the process will call a stored procedure with a lot of
So we have to optimize our current implementation of our indexing. Our
current implementation is to index per batch and each batch will have a
query call from the database that will return multiple result sets and the
application will be responsible in assembling the document based on the
result se
So we have a solr 6.6.3 deployed in AWS EC2 instance (dockerized) and during
our load testing, our script for some reason removed 1 replica. So I decided
to add 1 replica in the shard with only 1 replica and it returned the error
message in the title.
Whan can cause this? We have another collecti
Thank you very much for this reply!
Thank you for pointing out our error in having an ELB on top of a zookeeper.
We did this so that we could recover a node if it goes down without the need
to have a rolling restart of the solr nodes. I guess we will try an elastic
IP instead because part of our r
I need in help on our production setup so I will describe our setup and
issues below.
Solr is constantly going down even if there is no load / traffic. We have
recovery scripts for that but sometimes recovery is not going well because
nodes can't elect a leader so sometimes shards are unsusable /
Our team is having problems with our production setup in AWS.
Our current setup is:
- Dockerized solr nodes behind an ELB
- zookeeper with exhibitor in a docker container (3 of this set)
- solr talks to a zookeeper through an ELB (should we even do this? we did
this for recovery purposes so if the
19 matches
Mail list logo