设为首页 收藏本站
查看: 1084|回复: 0

[经验分享] solr性能调优

[复制链接]

尚未签到

发表于 2015-7-17 07:52:02 | 显示全部楼层 |阅读模式
Schema Design Considerations
   indexed fields
  indexed fields 的数量将会影响以下的一些性能:

  •         索引时的时候的内存使用量
  •         索引段的合并时间
  •         优化时间
  •         索引的大小
  我们可以通过 将 omitNorms=“true” 来减少indexed fields数量增加所带来的影响。
  
   stored fields
  Retrieving the stored fields  确实是一种开销。这个开销,受每个文档所存储的字节影响很大。每个文档的所占用的空间越大,文档就显的更稀疏,这样从硬盘中读取数据,就需要更多的i/o操作(通常,我们在存储比较大的域的时候,就会考虑这样的事情,比如存储一篇文章的文档。)
  可以考虑将比较大的域放到solr外面来存储。如果你觉得这样做会有些别扭的话,可以考虑使用压缩的域,但是这样会加重cpu在存储和读取域的时候的负担。不过这样却是可以较少i/0的负担。
  如果,你并不是总是使用 stored fields 的话,可以使用stored field的延迟加载,这样可以节省很多的性能,尤其是使用compressed field 的时候。
  
Configuration Considerations
      mergeFactor
  这个是合并因子,这个参数大概决定了segment(索引段)的数量。
  合并因子这个值告诉lucene,在什么时候,要将几个segment合并成为一个segment, 合并因子就像是一个数字系统的基数一样。
  
  比如说,如果你将合并因子设成10,那么每往索引中添加1000个文档的时候,就会创建一个新的索引段。当第10个大小为1000的索引段添加进来的时候,这十个索引段就会被合并成一个大小为10,000的索引段。当十个大小为10,000的索引段生成的时候,它们就会被合并成一个大小为100,000的索引段。如此类推下去。
  
  这个值可以在 solrconfig.xml 中的 *mainIndex*中设置。(不用管indexDefaults中设置)
       mergeFactor Tradeoffs
  较高的合并因子

  •         会提高索引速度
  •         较低频率的合并,会导致 更多的索引文件,这会降低索引的搜索效率
  较低的合并因子

  •         较少数量的索引文件,能加快索引的搜索速度。
  •         较高频率的合并,会降低索引的速度。
Cache autoWarm Count Considerations
  当一个新的 searcher 打开的时候,它缓存可以被预热,或者说使用从旧的searcher的缓存的数据来“自动加热”。autowarmCount是这样的一个参数,它表示从旧缓存中拷贝到新缓存中的对象数量。autowarmCount这个参数将会影响“自动预热”的时间。有些时候,我们需要一些折中的考虑,seacher启动的时间和缓存加热的程度。当然啦,缓存加热的程度越好,使用的时间就会越长,但往往,我们并不希望过长的seacher启动时间。这个autowarm 参数可以在solrconfig.xml文件中被设置。
  详细的配置可以参考solr的wiki。
Cache hit rate(缓存命中率)
  我们可以通过solr的admin界面来查看缓存的状态信息。提高solr缓存的大小往往是提高性能的捷径。当你使用面搜索的时候,你或许可以注意一下filterCache,这个是由solr实现的缓存。
  详细的内容可以参考 solrCaching这篇wiki。
Explicit Warming of Sort Fields
  如果你有许多域是基于排序的,那么你可以在"newSearcher"和"firstSearcher"event listeners中添加一些明显需要预热的查询,这样FieldCache 就会缓存这部分内容。
Optimization Considerations
  优化索引,是我们经常会做的事情,比如,当我们建立好索引,然后这个索引不会再变更的情况,我们就会做一次优化了。
  但,如果你的索引经常会改变,那么你就需要好好的考虑下面的因素的。

  •        当越来越多的索引段被加进索引,查询的性能就会降低, lucene对索引段的数量有一个上限的限制,当超过这个限制的时候,索引段可以自动合并成为一个。
  • 在同样没有缓存的情况下,一个没有经过优化的索引的性能会比经过优化的索引的性能少10%……
  • 自动加热的时间将会变长,因为它依赖于搜索。
  • 优化将会对索引的分发产生影响。
  • 在优化期间,文件的大小将会是索引的两倍,不过最终将会回到它原来的大小,或者会更小一点。
  优化,会将所有的索引段合并成为一个索引段,所以,优化这个操作其实可以帮助避免“too many files”这个问题,这个错误是由文件系统抛出的。
Updates and Commit Frequency Tradeoffs
  如果从机太经常从主机更新的话,从机的性能是会受到影响的。为了避免,由于这个问题而引起的性能下降,我们还必须了解从机是怎样执行更新的,这样我们才能更准确去调节一些相关的参数(commit的频率,spappullers,autowarming/autocount),这样,从机的更新才不会太频繁。

  •      执行commit操作会让solr新生成一个snapshot。如果将postCommit参数设成true的话,optimization也会执行snapShot.
  •      slave上的Snappuller程序一般是在crontab上面执行的,它会去master询问,有没有新版的snapshot。一旦发现新的版本,slave就会把它下载下来,然后snapinstall.
  •      每次当一个新的searcher被open的时候,会有一个缓存预热的过程,预热之后,新的索引才会交付使用。
  这里讨论三个有关的参数:

  •      number/frequency of snapshots  ----snapshot的频率。
  •      snappullers 是  在crontab中的,它当然可以每秒一次、每天一次、或者其他的时间间隔一次运行。它运行的时候,只会下载slave上没有的,并且最新的版本。
  •      Cache autowarming 可以在solrconfig.xml文件中配置。
  如果,你想要的效果是频繁的更新slave上的索引,以便这样看起来比较像“实时索引”。那么,你就需要让snapshot尽可能频繁的运行,然后也让snappuller频繁的运行。这样,我们或许可以每5分钟更新一次,并且还能取得不错的性能,当然啦,cach的命中率是很重要的,恩,缓存的加热时间也将会影响到更新的频繁度。
  cache对性能是很重要的。一方面,新的缓存必须拥有足够的缓存量,这样接下来的的查询才能够从缓存中受益。另一方面,缓存的预热将可能占用很长一段时间,尤其是,它其实是只使用一个线程,和一个cpu在工作。snapinstaller太频繁的话,solr slave将会处于一个不太理想的状态,可能它还在预热一个新的缓存,然而一个更新的searcher被opern了。
  怎么解决这样的一个问题呢,我们可能会取消第一个seacher,然后去处理一个更新seacher,也即是第二个。然而有可能第二个seacher 还没有被使用上的时候,第三个又过来了。看吧,一个恶性的循环,不是。当然也有可能,我们刚刚预热好的时候就开始新一轮的缓存预热,其实,这样缓存的作用压根就没有能体现出来。出现这种情况的时候,降低snapshot的频率才是硬道理。
    Query Response Compression
  在有些情况下,我们可以考虑将solr xml response 压缩后才输出。如果response非常大,就会触及NIc i/o限制。
  当然压缩这个操作将会增加cpu的负担,其实,solr一个典型的依赖于cpu处理速度的服务,增加这个压缩的操作,将无疑会降低查询性能。但是,压缩后的数据将会是压缩前的数据的6分之一 的大小。然而solr的查询性能也会有15%左右的消耗。
  至于怎样配置这个功能,要看你使用的什么服务器而定,可以查阅相关的文档。
     Embedded vs HTTP Post
  使用embeded 来建立索引,将会比使用xml格式来建立索引快50%。
  
     RAM Usage Considerations(内存方面的考虑)
        OutOfMemoryErrors
  如果你的solr实例没有被指定足够多的内存的话,java virtual machine也许会抛outof memoryError,这个并不对索引数据产生影响。但是这个时候,任何的 adds/deletes/commits操作都是不能够成功的。
         Memory allocated to the Java VM
  最简单的解决这个方法就是,当然前提是java virtual machine 还没有使用掉你全部的内存,增加运行solr的java虚拟机的内存。
  
           Factors affecting memory usage(影响内存使用量的因素)
  我想,你或许也会考虑怎样去减少solr的内存使用量。
  其中的一个因素就是input document的大小。
  当我们使用xml执行add操作的时候,就会有两个限制。

  •      document中的field都是会被存进内存的,field有个属性叫maxFieldLength,它或许能帮上忙。
  •      每增加一个域,也是会增加内存的使用的。

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-87418-1-1.html 上篇帖子: 使用 Apache Solr 实现更加灵巧的搜索 下篇帖子: Solr4.8.0源码分析(7)之Solr SPI
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表