The values you have for the caches and the maxwarmingsearchers do not look
like the default. Cache sizes are 512 for the most part and
maxwarmingsearchers are 2 (if not limit them to 2)
Sudden CPU spikes probably indicate GC issues. The # of documents you have
is small, are they huge documents? T
Thanks Alexandre, silly me. I though 8.4.1 was recent enough...
--
Sent from: https://lucene.472066.n3.nabble.com/Solr-User-f472068.html
I've stumbled upon
https://github.com/apache/lucene-solr/blob/visual-guide/solr/solr-ref-guide/src/logs.adoc
which looks very interesting for getting insights into the Solr logs.
I cannot find though postlogs command inside the Solr bin dir (there is post
command though) nor a way to create the lo
Hi Reinaldo,
Glad that helped. I've had several sleepless nights with Solr clusters
failing spectacularly in production due to that but I still cannot say that
the problem is completely away.
Did you check in the heap dump if you have cache memory leaks as described
in https://issues.apache.org/
I have faced similar issues and the culprit was filterCache when using
maxRAMMB. More specifically on a sharded Solr cluster with lots of faceting
during search (which makes use of the filterCache in a distributed setting)
I noticed that maxRAMMB value was not respected. I had a value of 300MB set
Jeff Courtade wrote
> Can we use GC1 garbage collection yet or do we still need to use CMS?
I believe you should be safe to go with G1. We've applied it in in a Solr
6.6 cluster with 10 shards, 3 replicas per shard and an index of about 500GB
(1,5T counting all replicas) and it works extremely wel
If you are having an issue when increasing the search request rate you should
have a look at maxConnectionsPerHost, I believe maxUpdateConnectionsPerHost
is related to indexing.
You can modify your solr.xml as follows (I believe it's not clear from the
official documentation, I had to go through t
In Solr there's /ExternalFileFieldReloader/ which is responsible for caching
the contents of external files whenever a new searcher is being warmed up.
It happens that I've defined a dynamic field to be used as an
/ExternalField/ as in
/* */
If you have a look inside the code /ExternalFileFiel
I believe that things like the following will affect faceting memory
requirements
-> how many fields do you facet on
-> what is the cardinality of each one of them
-> What is you QPS rate
but 2GB for 27M documents seems too low. Did you try to increase the memory
on Solr's JVM?
--
Sent from:
shamik wrote
> I was not aware of maxRamMB parameter, looks like it's only available for
> queryResultCache. Is that what you are referring to? Can you please share
> your cache configuration?
I've setup filterCache entry inside solrconfig.xml as follows
**
I had a look inside FastLRUCache code
I'll post my experience too, I believe it might be related to the low
FilterCache hit ratio issue. Please let me know if you think I'm off topic
here to create a separate thread.
I've run search stress tests on a 2 different Solr 6.5.1 installations
sending Distributed search queries with facets (
Another thing you can do - and which has helped me in the past quite a few
times - is to just run JVisualVM, attach to Solr's Java process and enable
the CPU sampler under the Sampler tab.
As you run indexing the methods that most time is spent on will appear near
the top.
--
Sent from: http:/
I've worked in the past for a Solr 5.x custom plugin using AspectJ to track
the # of calls as well as the time spent inside /incrementToken()/ of all
Tokenizers and Filters used during indexing. I could get stats per Solr
indexing thread, not per indexing request though. In any case you could spot
We are talking about fewer collections,so that won't be an issue.
The problem comes when - using the proposed setup - I want to send a query
across all those collections and get properly ranked results. Each
collection has its own IDF etc, so the scores are not comparable. This means
that most pr
I'm trying to setup a multi-tenant Solr cluster (v6.5.1) which must meet the
following requirements. The tenants are different customers with similar
type of data.
* Ability to query per client but also across all clients
* Don't want to hit all shards for all type of requests (per client, across
15 matches
Mail list logo