8

I am relatively new to SOLR. We are using SOLR 6.1.0.1 with Sitecore 8.1 Update 3. There are roughly 50K items (content and files) being indexed. We are being plagued by poor throughput (through put is about 77%), general slowness, and errors in logs such as consecutive full GC and errors such as

"Error opening new searcher. exceeded limit of maxWarmingSearchers=2".

The SOLR server has 8 cores and 16GB of memory. We are running 64bit version of Java in SOLR. I have increased the heap space to 4GB. I am not seeing Out of Memory exceptions in the SOLR logs. SOLR is installed on a single server. We are not using sharding, SOLR Cloud or an other distributed type SOLR instance.

Any Advice would be much appreciated

UPDATE

Sitecore eventually supplied me with a hotfix to resolve the problem. You can use the reference number 142962 to request a hotfix from Sitecore if you need it.

Improve this question
1
  • Not appreciated enough for you to respond or upvote those that tried to offer it.
    – Mark Cassidy ♦
    Commented Aug 7, 2018 at 9:03

5 Answers 5

Reset to default
3

There was no answer to this question so far, but the issue is quite common for Sitecore with SOLR, and is not really a huge problem, but rather a common WARN that occurs everywhere.

It appears when Sitecore indexing performs many commits to SOLR concurrently, causing this error when the searchers that are warming in the background exceed 2 (the default value is 2), you can increase that to solve the issue.

You will need to go to : <root>\solr\[CORE NAME]\conf\solrconfig.xml file and change the value of the maxWarmingSearchers to a higher value, for example to 4.

P.S. You can also check out this article for common SOLR issues: http://www.sitecorecoding.com/2015/08/solr-with-sitecore-checklist.html

P.S.S I would highly recommend everyone to use this script for an easy automated SOLR setup: https://gist.github.com/kamsar/ef8811bd458603f1e808

Improve this answer
3
  • Sitecore provided me a hotfix for this issue and since it was applied the error has gone away.
    – Mikeyp
    Commented Jul 9, 2018 at 12:56
  • You will still get this message in the solr control panel tho
    – Andrey Bobrov
    Commented Jul 9, 2018 at 13:07
  • Yes but much less than before
    – Mikeyp
    Commented Jul 10, 2018 at 14:42
1

Every time the index gets updated, a new searcher takes place and to prevent a long down time, Solr would already have warmed another searcher to be used once the index is updated.

If another update comes soon after, before using the first new searcher and second searcher gets warmed and so on. But Solr limits this behavior with the maxWarmingSearcher count.

If you keep seeing the maxWarmingSearcher exceeded message, i would guess Solr is getting too many index updates in short time spans. While it's switching searchers Solr would be slower.

So as a start, make sure you limit the index update requests.

Improve this answer
1

Do you have a dedicated server for SOLR? What kind of hard disks do you have for SOLR, SSD? Is SOLR on Linux or Windows?

Have you tried monitoring SOLR with something like https://sematext.com? Are any requests getting a high latency? (have you disabled the master index optimize master index job, only runs once every X hours so unlikely to be causing all your issues) Or monitored disk activity to see if that's a bottle neck?

How many collections do you have?

Are you sure the problem is on the SOLR server side? What about the sitecore crawling side? What does CPU look like on your indexing server? How have you configured parallel indexing, threads, batch sizes? How many cores do you have on the indexing server? How many requests per second are going to SOLR to update the index?

Hope this helps identify the root cause.

Improve this answer
13
  • The indexing server is the same as our CM Server and has 12 cores. We do not do any sort of scheduled publishing and there is a lot of publishing activity throughout the day. We do not do any full reindexing or full site publishes.
    – Mikeyp
    Commented Feb 12, 2018 at 20:13
  • My settings for java heap size and GC are as follows Set SOLR_JAVA_MEM=-Xms4096m -Xmx4096m set GC_TUNE=-XX:NewRatio=3 ^ -XX:SurvivorRatio=4 ^ -XX:TargetSurvivorRatio=90 ^ -XX:MaxTenuringThreshold=8 ^ -XX:+UseConcMarkSweepGC ^ -XX:+UseParNewGC ^ -XX:ConcGCThreads=4 -XX:ParallelGCThreads=4 ^ -XX:+CMSScavengeBeforeRemark ^ -XX:PretenureSizeThreshold=64m ^ -XX:+UseCMSInitiatingOccupancyOnly ^ -XX:CMSInitiatingOccupancyFraction=10 ^ -XX:CMSMaxAbortablePrecleanTime=6000 ^ -XX:+CMSParallelRemarkEnabled ^ -XX:+ParallelRefProcEnabled
    – Mikeyp
    Commented Feb 12, 2018 at 20:14
  • I can tell you that the CPU on our SOLR server bounces around ALOT. It bounces from between 10% to 70%
    – Mikeyp
    Commented Feb 12, 2018 at 20:16
  • If you just do a reindex in an environment not under load do you get same issues. E.g. one not getting any queries.
    – Ian
    Commented Feb 12, 2018 at 22:03
  • Are those just default GC values, or did you do any customisations. Only interested in custom values.
    – Ian
    Commented Feb 12, 2018 at 22:04
1

I am using Solr 4.10.4 with Sitecore 8.1 update 3, and it is working as expected with just 4GB RAM and 4 Cores; moreover I am indexing more than 10M document.

As per Sitecore Compatibility table, Sitecore 8.1 should be working fine with 4.10.x - It might be a compatibility issue.

Please read more here.

https://kb.sitecore.net/articles/227897

Improve this answer
1

If you are running xdb and and Solr runs the analytics index I would suspect the analytics index being the issue. Is the warning coming from the analytics index?

I think update 3 is the version where the setting of

It is default true but set it to false and it goes away but you will not see anonymous contacts in the experience profile.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.