如何大幅优化solr的查询solr5.0 性能优化

我个配置:JAVA_OPTIONS=&-Xmx1024m -Xms1024m -Xmn512m -XX:MaxPermSize=128m -XX:SurvivorRatio=65536 -XX:MaxTenuringThreshold=0 -Xnoclassgc -XX:+DisableExplicitGC -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 -XX:+CMSClassUnloadingEnabled -XX:-CMSParallelRemarkEnabled -XX:CMSInitiatingOccupancyFraction=51 -XX:SoftRefLRUPolicyMSPerMB=0 -XX:+PrintClassHistogram -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -Xloggc:logs/gc.log&JVM参数调优,这是很头痛的问题,设置的不好,JVM不断执行FullGC,导致整个系统变得很慢.要想配置好JVM参数,需要对年轻代、年老代、救助空间和永久代有一定了解,还要了解jvm内存管理逻辑,最终还要根据自己的应用来做调整。jvm参数调优给出以下几条经验:1:建议用64位操作系统,Linux下64位的jdk比32位jdk要慢一些,但是吃得内存更多,吞吐量更大。2:XMX和XMS设置一样大,MaxPermSize和MinPermSize设置一样大,这样可以减轻伸缩堆大小带来的压力。3:调试的时候设置一些打印JVM参数,如-XX:+PrintClassHistogram-XX:+PrintGCDetails-XX:+PrintGCTimeStamps-XX:+PrintHeapAtGC-Xloggc:log/gc.log,这样可以从gc.log里看出一些端倪出来。4:系统停顿的时候可能是GC的问题也可能是程序的问题,多用jmap和jstack查看,或者killall-3java,然后查看java控制台日志,能看出很多问题。有一次,网站突然很慢,jstack一看,原来是自己写的URLConnection连接太多没有释放,改一下程序就OK了。5:仔细了解自己的应用,如果用了缓存,那么年老代应该大一些,缓存的HashMap不应该无限制长,建议采用LRU算法的Map做缓存,LRUMap的最大长度也要根据实际情况设定。6:垃圾回收时promotionfailed是个很头痛的问题,一般可能是两种原因产生,第一个原因是救助空间不够,救助空间里的对象还不应该被移动到年老代,但年轻代又有很多对象需要放入救助空间;第二个原因是年老代没有足够的空间接纳来自年轻代的对象;这两种情况都会转向FullGC,系统停顿时间较长。第一个原因我的最终解决办法是去掉救助空间,设置-XX:SurvivorRatio=65536-XX:MaxTenuringThreshold=0即可,第二个原因我的解决办法是设置CMSInitiatingOccupancyFraction为某个值(假设70),这样年老代空间到70%时就开始执行CMS,年老代有足够的空间接纳来自年轻代的对象。7:不管怎样,永久代还是会逐渐变满,所以隔三差五重起java服务器是必要的,我每天都自动重起。8:采用并发回收时,年轻代小一点,年老代要大,因为年老大用的是并发回收,即使时间长点也不会影响其他程序继续运行,系统不会停顿。我的一个配置如下(系统8G内存),每天几百万pv一点问题都没有,网站没有停顿,没有因为内存问题down过机。$JAVA_ARGS.=&-Dresin.home=$SERVER_ROOT&-server-Xms6000M-Xmx6000M-Xmn500M&-XX:PermSize=500M-XX:MaxPermSize=500M&-XX:SurvivorRatio=65536&-XX:MaxTenuringThreshold=0&-Xnoclassgc&-XX:+DisableExplicitGC&XX:+UseParNewGC-XX:+UseConcMarkSweepGC&-XX:+UseCMSCompactAtFullCollection&-XX:CMSFullGCsBeforeCompaction=0&-XX:+CMSClassUnloadingEnabled&-XX:-CMSParallelRemarkEnabled&-XX:CMSInitiatingOccupancyFraction=90&-XX:SoftRefLRUPolicyMSPerMB=0-XX:+PrintClassHistogram&-XX:+PrintGCDetails-XX:+PrintGCTimeStamps-XX:+PrintHeapAtGC&-Xloggc:log/gc.log&;&说明一下:&&&-XX:SurvivorRatio=65536,-XX:MaxTenuringThreshold=0就是去掉了救助空间;-Xnoclassgc禁用类垃圾回收,性能会高一点;-XX:+DisableExplicitGC禁止System.gc(),免得程序员误调用gc方法影响性能;-XX:+UseParNewGC,对年轻代采用多线程并行回收,这样收得快;带CMS参数的都是和并发回收相关的,不明白的可以上网搜索;CMSInitiatingOccupancyFraction,这个参数设置有很大技巧,基本上满足(Xmx-Xmn)*(100-CMSInitiatingOccupancyFraction)/100&=Xmn就不会出现promotionfailed。在我的应用中Xmx是6000,Xmn是500,那么Xmx-Xmn是5500兆,也就是年老代有5500兆,CMSInitiatingOccupancyFraction=90说明年老代到90%满的时候开始执行对年老代的并发垃圾回收(CMS),这时还剩10%的空间是0兆,所以即使Xmn(也就是年轻代共500兆)里所有对象都搬到年老代里,550兆的空间也足够了,所以只要满足上面的公式,就不会出现垃圾回收时的promotionfailed;SoftRefLRUPolicyMSPerMB这个参数我认为可能有点用,我觉得没必要等1秒;网上其他介绍JVM参数的也比较多,估计其中大部分是没有遇到promotionfailed,或者访问量太小没有机会遇到,(Xmx-Xmn)*(100-CMSInitiatingOccupancyFraction)/100&=Xmn这个公式绝对是原创,真遇到promotionfailed了,还得这么处理。& Blog Archive
& Solr如何按照年月日facet分层查询 - 【Solr教程|Solr安装|Solr配置|Solr优化|Solr资料】
这里假设我们的时间字段是timestamp
在schema.xml配置如下
&field name=”timestamp” type=”date” indexed=”true” stored=”true” default=”NOW+8HOUR” multiValued=”false”/&
查询参数如下:
facet=true&facet.date=timestamp&facet.date.start=NOW/DAY-1DAY&facet.date.end=NOW/DAY%2B1DAY&facet.date.gap=%2B1DAY
facet=true
开启分层检索
facet.date=timestamp
按时间分层检索的字段(timestamp)
facet.date.start=NOW/DAY-1DAY
分层检索开始的时间:前一天 = 当天零点(NOW/DAY) – 一天(-1DAY)
facet.date.end=NOW/DAY%2B1DAY
分层检索结束的时间:明天 = 当天零点(NOW/DAY) – 一天(+1DAY)
加(+)号从URL提交时要urlencode得到%2B
&facet.date.gap=%2B1DAY
分层检索的间隔:每一天一组+1DAY
加(+)号从URL提交时要urlencode得到%2B
NOW,HOUR,DAY,MONTH,YEAR都是可以用的}

我要回帖

更多关于 solr 查询性能优化 的文章

更多推荐

版权声明:文章内容来源于网络,版权归原作者所有,如有侵权请点击这里与我们联系,我们将及时删除。

点击添加站长微信