lucene-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject lucene-solr:branch_7x: SOLR-11964: SOLR-11874: Docs for ulimits (system) and queryAnalyzerFieldType (spellcheck)
Date Mon, 19 Feb 2018 21:10:02 GMT
Repository: lucene-solr
Updated Branches:
  refs/heads/branch_7x 539225eff -> aac11fc12

SOLR-11964: SOLR-11874: Docs for ulimits (system) and queryAnalyzerFieldType (spellcheck)

(cherry picked from commit be7a811)


Branch: refs/heads/branch_7x
Commit: aac11fc1209e7afeee49b112630ec421000e9195
Parents: 539225e
Author: Erick Erickson <>
Authored: Mon Feb 19 13:07:53 2018 -0800
Committer: Erick Erickson <>
Committed: Mon Feb 19 13:09:52 2018 -0800

 solr/solr-ref-guide/src/spell-checking.adoc          |  3 +++
 .../src/taking-solr-to-production.adoc               | 15 +++++++++++++++
 2 files changed, 18 insertions(+)
diff --git a/solr/solr-ref-guide/src/spell-checking.adoc b/solr/solr-ref-guide/src/spell-checking.adoc
index 26ec194..9936ece 100644
--- a/solr/solr-ref-guide/src/spell-checking.adoc
+++ b/solr/solr-ref-guide/src/spell-checking.adoc
@@ -191,6 +191,9 @@ If set to `true`, this parameter reloads the spellchecker. The results
depend on
 This parameter specifies the maximum number of suggestions that the spellchecker should return
for a term. If this parameter isn't set, the value defaults to `1`. If the parameter is set
but not assigned a number, the value defaults to `5`. If the parameter is set to a positive
integer, that number becomes the maximum number of suggestions returned by the spellchecker.
+This field type's analyzer is used by the QueryConverter to tokenize the value for "q" parameter.
The field specified by this parameter should do minimal transformations, it's usually a best
practice to avoid types that aggressively stem or ngram for instance.
 If `true`, Solr will return suggestions that result in more hits for the query than the existing
query. Note that this will return more popular suggestions even when the given query term
is present in the index and considered "correct".
diff --git a/solr/solr-ref-guide/src/taking-solr-to-production.adoc b/solr/solr-ref-guide/src/taking-solr-to-production.adoc
index 7097526..ca0f4eb 100644
--- a/solr/solr-ref-guide/src/taking-solr-to-production.adoc
+++ b/solr/solr-ref-guide/src/taking-solr-to-production.adoc
@@ -246,6 +246,21 @@ The `bin/solr` script simply passes options starting with `-D` on to
the JVM dur
 SOLR_OPTS="$SOLR_OPTS -Dsolr.autoSoftCommit.maxTime=10000"
+=== File Handles and Processes (ulimit settings)
+Two common settings that result in errors on *nix systems are file handles and user processes.
It is common for the default limits for number of processes and file handles to default to
values that are too low for a large Solr installation. The required number of each of these
will increase based on a combination of the number of replicas hosted per node and the number
of segments in the index for each replica. The usual recommendation is to make processes and
file handles at least 65,000 each, unlimited if possible. On most *nix systems, this command:
+ulimit -a
+will show the currently-defined limits. It is strongly recommended that file handle and process
limits be permanently raised as above. The exact form of the command will vary per operating
system, and some systems require editing configuration files and restarting your server. Consult
your system administrators for guidance in your particular environment.
+If these limits are exceeded, the problems reported by Solr vary depending on the specific
operation responsible for exceeding the limit. Errors such as to "too many open files", "connection
error", and "max processes exceeded" have been reported, as well as SolrCloud recovery failures.
Since exceeding these limits can result in such varied symptoms it is _strongly_ recommended
that these limits be permanently raised as recommended above.
 == Running Multiple Solr Nodes Per Host
 The `bin/solr` script is capable of running multiple instances on one machine, but for a
*typical* installation, this is not a recommended setup. Extra CPU and memory resources are
required for each additional instance. A single instance is easily capable of handling multiple

View raw message