[
https://issues.apache.org/jira/browse/SOLR-14528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Gerlowski resolved SOLR-14528.
------------------------------------
Resolution: Invalid
> Hybris 1905 and Solr 7.7.2 CPU Performance issue
> ------------------------------------------------
>
> Key: SOLR-14528
> URL: https://issues.apache.org/jira/browse/SOLR-14528
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCLI
> Affects Versions: 7.7.2
> Reporter: Andrés Gutiérrez
> Priority: Major
> Labels: Debian, performance
> Attachments: SOLR TEST cliente pro SAP TUNNING - 12-05-2020.docx
>
>
> We write you from CEMEX Mexico, we use your solution through the HYBRIS
> E-Commerce from SAP, we have been with it for 3 years and we never had
> performance problems with it.
>
> But since the end of March of this year when we have migrated from version
> 6.3 of Hybris to 1905, the one that brings with it also the change in version
> in solr from 6.1.0 to 7.7.2. We have found that when Hybris performs solr
> tasks like modifying an index or full index, the CPU usage climbs and
> saturates, causing the server to crash.
>
>
> This was reported to the SAP people, who made us change the following
> configuration parameters without achieving significant changes on it:
> {color:#FF0000}(/etc/default/solr.in.sh){color}
> {color:#FF0000}SOLR_JAVA_MEM="-Xms8g -Xmx8g -XX:ConcGCThreads=2
> -XX:ParallelGCThreads=2"
> {color}{color:#FF0000}GC_TUNE="-XX:+UseG1GC -XX:+UnlockExperimentalVMOptions
> -XX:G1MaxNewSizePercent=70 -XX:+PerfDisableSharedMem
> -XX:+ParallelRefProcEnabled -XX:MaxGCPauseMillis=250 -XX:+UseLargePages
> -XX:+AlwaysPreTouch" {color}
> {color:#FF0000}(solrconfig.xml){color}
> {color:#FF0000} <indexConfig> {color}
> {color:#FF0000}
> <lockType>${solr.lock.type:native}</lockType>{color}
> {color:#FF0000} <mergeScheduler
> class="org.apache.lucene.index.ConcurrentMergeScheduler">{color}
> {color:#FF0000} <int
> name="maxMergeCount">2</int>{color}
> {color:#FF0000} <int
> name="maxThreadCount">1</int>{color}
> {color:#FF0000} </mergeScheduler>{color}
> {color:#FF0000} {color}
> {color:#FF0000} <mergePolicyFactory
> class="org.apache.solr.index.TieredMergePolicyFactory">{color}
> {color:#FF0000} <int
> name="maxMergeAtOnce">10</int>{color}
> {color:#FF0000} <int
> name="segmentsPerTier">20</int>{color}
> {color:#FF0000} </mergePolicyFactory>{color}
> {color:#FF0000} <ramBufferSizeMB>600</ramBufferSizeMB>{color}
> {color:#FF0000} </indexConfig>{color}
> This configuration changes made the server crash less often but it also made
> the indexation times much longer with a sustained high CPU usage. It is
> important to restate that no changes have been performed on our code
> regarding how indexation processes run, and this used to work quite well in
> the older solr version (6.1). (Tests and performance metrics can be found in
> the attached document named: _*SOLR TEST cliente pro SAP TUNNING -
> 12-05-2020.docx)*_
>
> On the other hand, they tell us that they see a significant change in this
> class and I quote
>
> "The methods that take most of the time are related to the
> Lucene70DocValuesConsumer class. You can find attached a PPT file with
> screenshots from Dynatrace and a stack trace from Solr.
>
> I inspected the source code of the file
> (https://github.com/apache/lucene-solr/blob/branch_7_7/lucene/core/src/java/org/apache/lucene/codecs/lucene70/Lucene70DocValuesConsumer.java)
> to see if it used any flags or configuration parameters that could be
> configured / tuned but that is not the case.
>
> This part of the Solr code is very different from the old one (Solr 6.1). I
> did not have enough time to trace all the method calls to reach a conclusion,
> but it is definitively doing
> things differently."
>
> And they ask us to raise a ticket with you to see if they can help us see
> that it could have changed so much that it brings us the consumption problems
> mentioned above.
>
> As it is the first time that we report a problem directly to you, we would
> like you to guide us in what we can pass on to you or how to take this
> problem to a prompt solution.
>
> We remain at your entire disposal (and immediately) for what you need for
> your analysis.
>
> Regards.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
