Apache
/
lucene
mirror of https://github.com/apache/lucene.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

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

This commit is contained in:
Erick Erickson 2018-02-19 13:07:53 -08:00
parent a2fdbc9353
commit be7a811f61
2 changed files with 18 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
solr/solr-ref-guide/src/spell-checking.adoc
View File

@ -191,6 +191,9 @@ If set to `true`, this parameter reloads the spellchecker. The results depend on
`spellcheck.count`:: `spellcheck.count`::
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 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.
`spellcheck.queryAnalyzerFieldtype`::
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.
`spellcheck.onlyMorePopular`:: `spellcheck.onlyMorePopular`::
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". 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".

15
solr/solr-ref-guide/src/taking-solr-to-production.adoc
View File

@ -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" 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:
[source,bash]
----
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.
[TIP]
====
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 == 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 indexes. 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 indexes.