[lucene-solr] branch branch_8x updated: SOLR-14263: stripping .adoc to fix build.

[mk...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

mkhl pushed a commit to branch branch_8x
in repository https://gitbox.apache.org/repos/asf/lucene-solr.git


The following commit(s) were added to refs/heads/branch_8x by this push:
     new 9f1aa42  SOLR-14263: stripping .adoc to fix build.
9f1aa42 is described below

commit 9f1aa427c015a7c797ec1b4efbb6874b1f1a2914
Author: Mikhail Khludnev <mk...@apache.org>
AuthorDate: Wed Feb 19 13:53:12 2020 +0300

    SOLR-14263: stripping .adoc to fix build.
---
 solr/solr-ref-guide/src/jvm-settings.adoc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/solr/solr-ref-guide/src/jvm-settings.adoc b/solr/solr-ref-guide/src/jvm-settings.adoc
index 99aa655..f3114ce 100644
--- a/solr/solr-ref-guide/src/jvm-settings.adoc
+++ b/solr/solr-ref-guide/src/jvm-settings.adoc
@@ -35,7 +35,7 @@ There are several points to keep in mind:
  * The heap allocated should be as small as possible while maintaining good performance. 8-16G is quite common, and larger heaps are sometimes used. When heaps grow to larger sizes, it is imperative to test extensively before going to production.
  * The G1GC garbage collector is currently preferred when using a JVM that supports it (Java 9 and later)
  * Modern hardware can be configured with hundreds of gigabytes of physical RAM and many CPUs. It is often better in these cases to run multiple JVMs, each with a limited amount of memory allocated to their heaps.
- * It's good practice to periodically re-analyze the GC logs and/or monitor with  <<metrics-reporting.adoc#metrics-reporting,Metrics Reporting>> to see if the memory usage has changed due to changes in your application, number of documents, etc.
+ * It's good practice to periodically re-analyze the GC logs and/or monitor with  <<metrics-reporting#metrics-reporting,Metrics Reporting>> to see if the memory usage has changed due to changes in your application, number of documents, etc.
  * On *nix systems, we recommend that Solr be run with the "oom killer script" (see solr/bin/oom_solr.sh). This will forcefully stop Solr when the heap is exhausted rather than continue in an indeterminate state.
  * All current (Java 11) garbage collectors can hit "stop the world" collections, which suspend the JVM until completed. If, through monitoring, these collections are frequent and greater than your application can tolerate, additional tuning should be considered. "Stop the world" pauses greater than 5 seconds are rarely acceptable, and having them be less than 1 second is desirable.