  
 |
Optionally, if advised by customer support, you can add the following values to the ignite.ini file.
| Parameter | Description |
|---|---|
| RFLOG | Directory where the Search Service writes its logs. The default is the SearchServerInstall/logs subdirectory. Edit this value only if you change this directory; the new directory must exist and must be writable by the Search Service. |
| RF_HIGH_PRIORITY | If this parameter is set to any value, Search Service attempts to increase its process priority over that of other processes. This is not normally necessary, but might be useful on a computer where other processes compete for resources with the Search Service. |
| RF_MAX_WILDCARD_EXPANSIONS | When a user enters a query that uses a wildcard (for example, “plum*”), this parameter determines the maximum number of terms into which the wildcard is expanded (for example, plum, plums, plumber). The default is 100 terms. This limit keeps overly general queries (“*ing”) from expanding into a huge number of terms and consuming too much time and memory. In large installations, you might need to increase this value. |
| RF_MAX_QUERY_MSECS | Maximum time, in milliseconds, for user queries. The default is 10000 (ten seconds). After processing the query for this much time, the Search Service returns results it has found so far. You might want to lower the value of this parameter if end users complain that ten seconds is too long to wait for query results. |
| RF_MAX_TOTAL_RESULTS | Maximum number of results returned by a query. The default is 10000. You do not generally need to change this parameter because the portal displays fewer results than the Search Service maximum. |
| RF_MAX_NUM_STATIC_ARCHIVES | Maximum number of static archives per collection created in the index directory. The default is 50; this means that there will be up to 50 archive.NNN.docset files (where NNN is a number), archive.NNN.index files, and so on. There can also be up to 50 spell.NNN.docset files, spell.NNN.index files, and so forth. You do not generally need to change this parameter; the only reason might be an operating system (such as Solaris 2.6) that does not allow the Search Service to use enough file descriptors to open all the files at once. Lowering this number causes archive merges to use more memory and disk space. |
| RF_QUERY_THREADS | Number of threads to dedicate to query processing. The default is 8. You might need to increase this parameter if your Search Service is under heavy load. The value should represent the expected number of simultaneous queries. If this value is too low, incoming queries will wait on a queue for the next free query thread and users will experience longer query times (possibly several seconds). |
| RF_QUERY_QUEUE_SIZE | When all Search Service query threads (see RF_QUERY_THREADS) are busy, incoming query requests are placed on a queue to wait for the next available query thread. This parameter determines the length of that queue. The default value is 20 and usually does not need to be changed. Should the query queue ever become full, additional query requests are rejected and a message is written to the Search Service logs. If this happens, you can increase RF_QUERY_QUEUE_SIZE. |
| RF_INDEX_THREADS | Number of threads to dedicate to indexing requests. The default is 2. You might need to increase this parameter if the indexing performance of your Search Service is too low. However, devoting additional system resources to indexing will reduce query performance. Ideally, the value of RF_INDEX_THREADS should not exceed the number of CPUs on the system. |
| RF_INDEX_QUEUE_SIZE | When all Search Service index threads (see RF_INDEX_THREADS)
are busy, incoming index requests are placed on a queue to wait for
the next available index thread. This parameter determines the length
of that queue. The default value is 20. To estimate a good value,
add the number of threads in all content crawlers that might be running
simultaneously (you can request up to four threads when setting up
a content crawler). To be conservative, make your estimates high.
If this parameter is too low, content crawlers can fill the index
queue and the Search Service rejects additional index requests until
the queue has room for more requests. Note: It is better to schedule
nonoverlapping crawls than to set a high value for RF_INDEX_QUEUE_SIZE;
consider changing the crawl schedule before modifying this parameter.
|
| RF_HANDSHAKE_THREADS | Number of threads to dedicate to servicing incoming socket connections. The default is 5. This value should never need to be changed. |
| RF_HANDSHAKE_QUEUE_SIZE | Socket connections from Search Service clients are placed on this queue to await acknowledgement by one of the handshake threads (see RF_HANDSHAKE_THREADS). This parameter determines the length of that queue. The default value is 20. Once successfully acknowledged, the connections are assigned to either the query or index queue. Under exceptionally high loads, this queue might fill up and the Search Service will reject new connections until the queue has room for more requests. Should this happen, you can increase the value of this parameter. |
| RF_TOKEN_LEXICON_REBUILD_LIMIT | Maximum lexicon size, measured in number of tokens, to rebuild
automatically. If the Search Service detects that the lexicon was
closed improperly, the lexicon is rebuilt as part of the startup process.
This can be time consuming. The default value is 400000, ensuring
that the rebuild requires no more than a few minutes. Larger lexicons
needing repair must be rebuilt with the standalone examinearchive
utility. You might change the value or set it to zero to allow automatic
rebuild of arbitrarily large lexicons. In Windows Systems: Setting this value too large can result in error dialogs being posted by the Windows Service Control Manager when the Search Service is run as a Windows service and a lexicon rebuild is performed. These error dialogs indicate that the service is failing to start in a timely manner. They can be disregarded. |
| RF_USE_DATA_FILE_CACHE | Numeric parameter indicating whether the Search Service should
use caches when accessing index and document data. A value of zero
disables the caches and causes the Search Service to use memory-mapping.
A nonzero value activates the caches. The default value is 1. We strongly
recommend you do not change this value. This parameter serves as the master on/off switch for RF_INDEX_CACHE_BYTES, RF_DOCSET_CACHE_BYTES, RF_INDEX_CACHE_MAX_PAGES_PER_BLOCK, and RF_DOCSET_CACHE_MAX_PAGES_PER_BLOCK. When RF_USE_DATA_FILE_CACHE is zero, these other parameters have no effect. Disabling the caches for small search collections (less than 1 gigabyte of data) might provide a slight improvement in performance depending upon the amount of available physical memory on the Search Service host. In memory-mapped mode, the Search Service fails if the index and document data, plus the Search Service's internal data structures should exceed 2 or 3 gigabytes (depending upon the operating system configuration). |
| RF_REQUIRED_DISK_SPACE | Amount of disk space (in KB) required to start a dynamic index merge. When merging dynamically indexed data into the search collection, the Search Service verifies that this amount of free space is available on the volume containing the search collection. If the space is not available, the merge process aborts, the Search Service enters read-only mode, and further dynamic indexing requests are rejected. The default value for this parameter is 40000 and should not need to be changed. |
   |