Apache Solr Reference Guide Covering Apache Solr 6.0

the signature of the jar that you got in Step 4.
curl http://localhost:8983/solr/techproducts/config -H
'Content-type:application/json' -d '{
"add-runtimelib": {
"name":"blobname",
"version":2,
"sig":"mW1Gwtz2QazjfVdrLFHfbGwcr8xzFYgUOLu68LHqWRDvLG0uLcy1McQ+AzVmeZFBf1yLPDEHBWJb5
KXr8bdbHN/
PYgUB1nsr9pk4EFyD9KfJ8TqeH/ijQ9waa/vjqyiKEI9U550EtSzruLVZ32wJ7smvV0fj2YYhrUaaPzOn9g0
=" }
}'
JVM Settings
Configuring your JVM can be a complex topic. A full discussion is beyond the scope of this document. Luckily,
most modern JVMs are quite good at making the best use of available resources with default settings. The
following sections contain a few tips that may be helpful when the defaults are not optimal for your situation.
For more general information about improving Solr performance, see https://wiki.apache.org/solr/SolrPerformanc
eFactors.
Choosing Memory Heap Settings
The most important JVM configuration settings are those that determine the amount of memory it is allowed to
allocate. There are two primary command-line options that set memory limits for the JVM. These are -Xms,
which sets the initial size of the JVM's memory heap, and -Xmx, which sets the maximum size to which the heap
is allowed to grow.
If your Solr application requires more heap space than you specify with the -Xms option, the heap will grow
automatically. It's quite reasonable to not specify an initial size and let the heap grow as needed. The only
downside is a somewhat slower startup time since the application will take longer to initialize. Setting the initial
heap size higher than the default may avoid a series of heap expansions, which often results in objects being
shuffled around within the heap, as the application spins up.
The maximum heap size, set with -Xmx, is more critical. If the memory heap grows to this size, object creation
may begin to fail and throw OutOfMemoryException. Setting this limit too low can cause spurious errors in
your application, but setting it too high can be detrimental as well.
It doesn't always cause an error when the heap reaches the maximum size. Before an error is raised, the JVM
will first try to reclaim any available space that already exists in the heap. Only if all garbage collection attempts
fail will your application see an exception. As long as the maximum is big enough, your app will run without error,
but it may run more slowly if forced garbage collection kicks in frequently.
The larger the heap the longer it takes to do garbage collection. This can mean minor, random pauses or, in
extreme cases, "freeze the world" pauses of a minute or more. As a practical matter, this can become a serious
problem for heap sizes that exceed about two gigabytes, even if far more physical memory is available. On
robust hardware, you may get better results running multiple JVMs, rather than just one with a large memory
heap. Some specialized JVM implementations may have customized garbage collection algorithms that do better
with large heaps. Consult your JVM vendor's documentation.
When setting the maximum heap size, be careful not to let the JVM consume all available physical memory. If
the JVM process space grows too large, the operating system will start swapping it, which will severely impact
performance. In addition, the operating system uses memory space not allocated to processes for file system
Apache Solr Reference Guide 6.0
501