在生产库安装SOLR

文章主要来源于对官方文档的翻译:

1. 压缩包bin目录有个install_solr_service.sh脚本，帮助你安装solr作为一个服务。目前支持CentOS, Debian, Red Hat, SUSE 和 Ubuntu Linux系统。

2. 为了方便升级，建议将安装目录和solr数据文件的目录分开，并且为安装目录创建软连接(这些事情install_solr_service.sh都会为你做，你仅需指定目录,-i 选项可以指定安装目录)。

   假如版本为7.7，并且采用默认安目录(/opt),软连接方式如下:

   /opt/solr-7.7.0

   /opt/solr -> /opt/solr-7.7.0

3. 不建议用root用户运行solr，所以install_solr_service.sh会为你创建默认用户solr，用户solr将是solr系统的启动者和文件拥有者(可以通过ps -ef|grep java验证,ls -ls命令也可以验证solr文件的拥有者)。-u选项可以指定用户替代默认的solr。

   4. 具体安装步骤(其实安装只需执行这一步，其他都是对这一步的说明)

• 解压:  tar xzf solr-7.7.0.tgz solr-7.7.0/bin/install_solr_service.sh --strip-components=2（用root用户执行）

• 安装: sudo bash ./install_solr_service.sh solr-7.7.0.tgz（用root用户执行），该命令等价于sudo bash ./install_solr_service.sh solr-7.7.0.tgz -i /opt -d /var/solr -u solr -s solr -p 8983(-i指定SOLR安装目录，-d指定SOLR数据目录，-u指定SOLR系统的启动和文件所有用户，-p指定SOLR启动端口)

    5. 启动和关闭，重启命令,查看状态

       service solr start service solr stop service solr restart service solr status

   6.  安装目录bin下的solr.sh脚本里有默认的数据目录位置等启动参数配置，也可以传递参数覆盖脚本里的配置(如-Dsolr.solr.home=…可以指定数据目录)。但强烈建议使用SOLR系统的配置文件，通常该文件是:/etc/default/solr.in.sh(该文件的目录可以在执行安装脚本install_solr_service.sh，用-s选项替代默认路径)，里面有所有涉及到的参数。

    该配置文件至少配置了一下几项:

    SOLR_PID_DIR="/var/solr"    

    SOLR_HOME="/var/solr/data"

    LOG4J_PROPS="/var/solr/log4j2.xml"

    SOLR_LOGS_DIR="/var/solr/logs"  --日志文件目录

    SOLR_PORT="8983"

   7. init.d脚本。将solr安装为服务(即用install_solr_service.sh安装)，会生成/etc/init.d/solr文件，用于帮助你管理solr服务(即可以用servce solr命令操           作，该脚本有启动需要的位置信息，如下（如果采用默认安装）:

       SOLR_INSTALL_DIR=/opt/solr   --solr的安装目录

       SOLR_ENV=/etc/default/solr.in.sh  ---solr服务的配置文件

       RUNAS=solr   ---这里指定操作系统用户名，即solr服务的所属服务

        ).

  8. 错误日志文件: /var/solr/logs/solr.log

  9. 调优部分

  Dynamic Defaults for ConcurrentMergeScheduler并发合并调度器的动态默认值

  Merge Scheduler在solrconfig.xml(每个核心都有该配置文件,/var/solr/data/test_core/conf/solrconfig.xml)配置。Merge Scheduler会启动多个后台线 程合并Lucene段(Lucene segments)。

 默认情况下，ConcurrentMergeScheduler.会自动检测硬盘的类型:

 如果是机械硬盘（rotational disk）: maxThreadCount=1 maxMergeCount=6

 如果是固态硬盘 （SSD）:  maxThreadCount=4 or CPU数的一半(指分给JVM的CPU，哪个值大就为哪个)。maxMergeCount=maxThreadCount+5

  在LINUX系统中，系统会自动检测硬盘类型，即使如此，也不能保证完全检测正确。其他系统都当机械硬盘处理。所以，这两个值的默认值是可能存在问题。而且这两个值对性能影响很大，所以最好手工修正(官方文档73页)。

系统自动检测的数据可以通过Metrics API获取(solr.node:CONTAINER.fs.coreRoot.spins如果true表示是机械硬盘)。

建议: (一)最好在solrconfig.xml配置文件中根据你用的硬盘指定maxThreadCount和maxMergeCount两个值。

             例如: 

                <mergeScheduler class="org.apache.lucene.index.ConcurrentMergeScheduler">

                     <int name="maxMergeCount">9</int>  --该行需自行在solrconfig.xml添加

                     <int name="maxThreadCount">4</int>  --该行需自行在solrconfig.xml添加

                </mergeScheduler>

        (二) 

            Alternatively, the boolean system property lucene.cms.override_spins can be set in the SOLR_OPTS

            variable in the include file to override the auto-detected value. Similarily, the system property

            lucene.cms.override_core_count can be set to the number of CPU cores to override the auto-detected

            processor count.

            注释: 可选择的方法, 这里说可以在/etc/default/solr.in.sh文件中手动指定CPU数和硬盘类型。大概添加的内容如下（因为未找到，也未试过，建议用上面的方法）:

            SOLR_OPTS="$SOLR_OPTS -Dsolr.clustering.enabled=true" ---文件已有的内容

            SOLR_OPTS="$SOLR_OPTS -Dsolr.lucene.cms.override_spins=true" ---自己添加

            SOLR_OPTS="$SOLR_OPTS -Dsolr.lucene.cms.override_core_count=2" --自己添加

   内存设置和垃圾回收(Memory and GC Settings)--Garbage Collection 垃圾回收

    在/etc/default/solr.in.sh文件设置(默认为512M)

    SOLR_JAVA_MEM="-Xms512m -Xmx512m"---默认内容，可以根据实际情况修改，如改成10G: SOLR_JAVA_MEM="-Xms10g -Xmx10g"

    SOLR自带了一组JAVA 垃圾回收的配置参数，对很多情况都比较合理，但对一些特别的SOLR情况，可能需要调整这些参数，就需要修改GC_TUNE变量在 /etc/default/solr.in.sh文件中。(JVM配置垃圾回收可以问其他人员)

   当OutOfMemoryError异常抛出，JVM会调用/opt/solr/bin/oom_solr.sh，这个脚本会发出kill -9命令，杀掉solr进程。这在SolrCloud mode模式是推荐的。可以看一下该脚本的内容，明白JVM出现异常后的的动作。

   JAVA JVM参数设置一般原则:

   -Xms指定初始化的堆大小 -Xmx指定堆的最大内存大小。当所需内存超过初始内存大小时，堆大小会慢慢自动扩展。

   根据应用实际所用内存，调大初始内存参数是合理的。因为初始大小较大，只会影响启动速度(启动时，初始化内存时慢些)，却可以避免后面的堆扩展，因为程序需要时再扩展，会引起应用等待。

    -Xmx的设置更关键，因为程序使用的内存超过这个值，对象创建可能会产生错误并抛出OutOfMemoryException.设置太大也会是不利的。

   当内存使用达到最大值参数时，垃圾回收机制会回收空闲内存，只有回收尝试失败时，才会向应用抛出异常。只要内存参数设置足够大时，应用运行就不会出错，如果频繁强制内存垃圾回收时，系统运行将变得很慢(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)。

  内存堆越大，内存垃圾回收的时间也越长。更糟糕的是，还会出现随机停顿，更严重的是，系统有时会停顿1分钟甚至更多。------JAVA开发人员说JVM回收内存，是自动隔一段时间回收

  当内存堆使用超过2G时(tow gigabytes)时，将会成为1个问题，即使操作系统还有很多可用内存。

  如果操作系统资源有于，一般建议开多个JVMS,而不是一个JVM使用很大的内存(当然，可能有些JVM供应商，客制了一些特定的回收机制，能够处理大内存堆)。

  不要让JVM使用操作系统的所有可用内存，因为操作系统会需要缓存文件句柄或做其他工作。尽量避免操作系统交换内存空间到磁盘，这会大大影响性能。

   对于读写频繁的SOLR，要给操作系统留足够多的内存。这个配置临界值，最好经过多次实际的实验。(1308页)