11.05.2016 Views

Apache Solr Reference Guide Covering Apache Solr 6.0

21SiXmO

21SiXmO

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

<strong>Solr</strong> process PID running on port 8983<br />

{<br />

"version":"5.0.0 - ubuntu - 2014-12-17 19:36:58",<br />

"startTime":"2014-12-19T19:25:46.853Z",<br />

"uptime":"0 days, 0 hours, 0 minutes, 8 seconds",<br />

"memory":"85.4 MB (%17.4) of 490.7 MB"}<br />

If the status command is not successful, look for error messages in /var/solr/logs/solr.log.<br />

Fine tune your production setup<br />

Memory and GC Settings<br />

By default, the bin/solr script sets the maximum Java heap size to 512M (-Xmx512m), which is fine for getting<br />

started with <strong>Solr</strong>. For production, you’ll want to increase the maximum heap size based on the memory<br />

requirements of your search application; values between 10 and 20 gigabytes are not uncommon for production<br />

servers. When you need to change the memory settings for your <strong>Solr</strong> server, use the SOLR_JAVA_MEM variable<br />

in the include file, such as:<br />

SOLR_JAVA_MEM="-Xms10g -Xmx10g"<br />

Also, the include file comes with a set of pre-configured Java Garbage Collection settings that have shown to<br />

work well with <strong>Solr</strong> for a number of different workloads. However, these settings may not work well for your<br />

specific use of <strong>Solr</strong>. Consequently, you may need to change the GC settings, which should also be done with the<br />

GC_TUNE variable in the /etc/default/solr.in.sh include file. For more information about tuning your<br />

memory and garbage collection settings, see: JVM Settings.<br />

Out-of-Memory Shutdown Hook<br />

The bin/solr script registers the bin/oom_solr.sh script to be called by the JVM if an OutOfMemoryError<br />

occurs. The oom_solr.sh script will issue a kill -9 to the <strong>Solr</strong> process that experiences the OutOfMemoryE<br />

rror. This behavior is recommended when running in <strong>Solr</strong>Cloud mode so that ZooKeeper is immediately<br />

notified that a node has experienced a non-recoverable error. Take a moment to inspect the contents of the /op<br />

t/solr/bin/oom_solr.sh script so that you are familiar with the actions the script will perform if it is invoked<br />

by the JVM.<br />

<strong>Solr</strong>Cloud<br />

To run <strong>Solr</strong> in <strong>Solr</strong>Cloud mode, you need to set the ZK_HOST variable in the include file to point to your<br />

ZooKeeper ensemble. Running the embedded ZooKeeper is not supported in production environments. For<br />

instance, if you have a ZooKeeper ensemble hosted on the following three hosts on the default client port 2181<br />

(zk1, zk2, and zk3), then you would set:<br />

ZK_HOST=zk1,zk2,zk3<br />

When the ZK_HOST variable is set, <strong>Solr</strong> will launch in "cloud" mode.<br />

ZooKeeper chroot<br />

If you're using a ZooKeeper instance that is shared by other systems, it's recommended to isolate the <strong>Solr</strong>Cloud<br />

znode tree using ZooKeeper's chroot support. For instance, to ensure all znodes created by <strong>Solr</strong>Cloud are stored<br />

<strong>Apache</strong> <strong>Solr</strong> <strong>Reference</strong> <strong>Guide</strong> <strong>6.0</strong><br />

507

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!