阅读背景:

solrcloud使用中遇到的问题及解决方式

来源:互联网 

首先声明,我们团队在使用solrcloud过程中踩了一些坑,同事(晓磊和首富)进行了总结,我列到我的博客上做记录用:

Q:为什么Solr里面的时间比数据库里面早8小时?

Solr默认采用的时区是UTC时区,而DB中用的则是CST时区,这两个时区本身就相差了8个小时。可以通过修改Solr启动配置SOLR_TIMEZONE="UTC+08:00"将时区设置为CST。注意:修改SOLR_TIMEZONE只在导入数据时起到自动转换时区的作用。即使修改了以上配置,Solr在展示数据时任然采用UTC时区,通过solrj交互时任然需要手动转换时区。

Q:Solr集群配置域名无法作用。

在搭建Solr集群时,不同机器上的核心具有不同的命名例如:

127.0.0.1:8983上有financeLog_shard1_replca1核

127.0.0.2:8983上有financeLog_shard1_replca2核

127.0.0.3:8983上有financeLog_shard1_replca3核

三个核共同组成了名为financeLog的集群。

如果为三台机器配置solr.nonobank.com域名,通过ngx来做负载均衡是不行的,因为在具体方位时url中需要指定相应的核名。如

https://127.0.0.1:8983/solr/financeLog_shard1_replica1

解决方案,通过solrj提供的SolrCloudClient,通过Zookeeper地址进行访问。

Q:SolrClient连接Zookeeper超时问题

SolrClient首次连接需要较长的时间可以通过setZkConnectTimeout()方法设置一个较长的超时时间。

Q:关于Solr中文分词问题

Solr对中文的原生支持较差,只能单个字分词,如“真开心”只能分词成:真、开、心,这样在搜索“心开”时该条同样会被搜索出来,这不是我们所想要的。

解决方案:使用ICUTokenizer替代solr默认的Tokenizer,ICUTokenizer对中文有较好的分词,可以将“真开心”只能分词成:真、开心、真开心。

Q:如何记录较慢的查询

在Solr启动配置中添加<slowQueryThresholdMillis>1000</slowQueryThresholdMillis>将超过1s的查询记录。

Q:Solr日志量太大

可以将CONSOLE的日志级别由INFO调整为WARN;或者控制日志文件的大小,如:

log4j.appender.CONSOLE=org.apache.log4j.RollingFileAppender

log4j.appender.CONSOLE.MaxFileSize=1000MB

log4j.appender.CONSOLE.MaxBackupIndex=10

保证最多记录10G的日志文件。

Q:修改Solr配置是否需要重启服务器

Solr的配置文件分为两部分,一部分留在本地,一部分留在Zookeeper,留在Zookeeper的配置只需先下载,再修改,最后再上传回Zookeeper即可,无需重启。留在本地的配置修改后需要重启当前服务器才会生效。

使用bin目录下的zkcli.sh脚本完成配置文件的上传下载。

Q:Solr集群无法恢复

Solr集群恢复在最坏的情况下需要2倍当前core的存储空间,所以有时会出现磁盘空间不够的情况。

Q:通过solr自带的delta-import增量导入会丢数据

Solr本身会记录最后一次执行增量导入的时间,设为time1,下一次通过执行 SELECT * FROM finance_log WHERE update_time >= time1 找出增量数据。

丢失数据的根本原因在于DB中一条记录的update_time并不是该条记录实际提交的时间(即出现在DB中的时间)。

例如, DB在8:00:00执行一条update语句更新一条数据data后,data的update_time会被设置为8:00:00,而对应事务实际提交(执行commit)的时间可能是 8:00:20。假设Solr在8:00:10时执行增量导入,执行后会记录最后一次更新时间为8:00:10,此时由于data的更新状态尚未被提交,其对应Solr数据不会被更新。下一次执行增量导入时通过SELECT * FROM finance_log WHERE update_time >= 8:00:10找出增量的数据时并不包含data,即data被丢失了。

 

性能方面

solr上线后我们发现了几个性能方面的问题

Q: Solr在多核情况下只能使用一个CPU,如下图所示,一共有8个核,永远只有一个核在工作

 

分析:有可能和我们的VM配置有关,我们换成多CPU单核的情况下(8个CPU),CPU使用率上去了

Q:Solr GC 吞吐量低,如下图所示,gc的吞吐量只有85%

分析: 初步怀疑是young heap设置了太小

解决方案:使用G1GC,增大了Xmn后吞吐量提升很明显 (85%-> 98%)

 

Q:Out of Memory

分析:观察log发现有很多OOM的错误,通过分析一台solr的JVM Heap,发现solr dump中的FieldCache占了大约5G(不能被GC),fieldCache这个配置在solrcloud不能控制,是底层的lucene来控制,它是用来做sorting 和faceting的,也就是说我们业务中会在solr中进行大批量数据的排序(比如拿最大值是时候)。

解决方案:优化业务方每一次取排序数据的量

 

 


分享到: