Solr性能调优。

拼搏现实的明天。 2024-02-18 16:02 3阅读 0赞

## Schema Design Considerations ##

### indexed fields ###

> index fields的数量将会影响以下的一些性能：
> 
>  *  索引时的时候的内存使用量。
>  *  索引段的合并时间。
>  *  优化时间。
>  *  索引的大小。  
>     
> 
> 我们可以通过将omitNorms = "true"来减少indexed fields数量增加所带来的影响。

### stored fields ###

> Retrieving the stored fields确实是一种开销。这个开销，受每个文档所存储的字节影响很大。每个文档的所占用的空间越大，文档就显得更稀疏，这样从硬盘中读取数据，就需要更多的 i/o 操作（通常，我们在存储比较大的域的时候，就会考虑这样的事情，比如存储一篇文章的文档。）
> 
> 可以考虑将比较大的域放到 solr 外面来存储。如果你觉得这样做会有些别扭的话，可以考虑使用压缩的域，但是这样会加重 CPU 在存储和读取域的时候的负担。不过这样却是可以减少 i/o 的负担。
> 
> 如果，你并不是总是使用stored fields的话，可以使用stored field的延迟加载，这样可以节省很多的性能，尤其是使用compressed field 的时候。

## Configuration Considerations    ##

### mergeFactor ###

> 这个是合并因子，这个参数大概决定了 segment（索引段）的数量。
> 
> 合并因子这个值告诉lucene，在什么时候，要将几个segment合并成一个segment，合并因子就像是一个数字系统的基数一样。
> 
> 比如说，如果你将合并因子设成10，那么每往索引中添加1000个文档的时候，就会创建一个新的索引段。当第10个大小为1000的索引添加进来的时候，这十个索引段就会被合并成一个大小为10,1000的索引段。当十个大小为10,000的索引段生成的时候，他们就会ibei合并成一个大小为100,000的索引段。如此类推下去。
> 
> 这个值可以在solrconfig.xml中的\*mainIndex\*中设置。（不用管indexDefaults中设置）

### mergeFactor Tradeoffs ###

> **较高的合并因子**
> 
>  *  会提高索引速度。
>  *  较低频率的合并，会导致更多的索引文件，这会降低索引的搜索效率。
> 
> **较低的合并因子**
> 
>  *  较少数量的索引文件，能加快索引的搜索速度。
>  *  较高频率的合并，会降低索引的速度。

## Cache autoWarm Count Considerations ##

> 当一个新的searcher打开的时候，他缓存可以被预热，或者说使用从旧的searcher的缓存的数据来“自动加热”。autowarmCount是这样的一个参数，他表示从旧缓存中拷贝到新缓存中的对象数量。autowarmCount这个参数将会影响“自动预热”的时间。有些时间，我们需要一些折中的考虑，searcher启动的时间和缓存加热的程度。当然，缓存加热的程度越好，使用的时间就会越长，但往往，我们并不希望过长的searcher启动时间。这个autowarm参数可以在solrconfig.xml文件中被设置。

## Cache hit rate（缓存命中率） ##

> 我们可以通过solr的admin界面来查看缓存的状态信息。提高solr缓存的大小往往是提高性能的捷径。当你使用面搜索的时候，你或许可以注意一下filterCache，这个是由solr实现的缓存。

## Explicit Warming of Sort Fields ##

> 如果你有许多域是基于排序的，那么你可以在“newSearcher”和“firstSearcher” eventlisteners中添加一些明显需要预热的查询，这样 FieldCache 就会缓存这部分内容。

## OptimizationConsiderations ##

> 优化索引，是我们经常会做的事情，比如，当我们建立好索引，然后这个索引不会再变更的情况，我们就会做一次优化了。
> 
> 但，如果你的索引经常会改变，那么你就需要好好的考虑下面的因素的。
> 
> 当越来越多的索引段被加进索引，查询的性能就会降低，lucene对索引段的数量有一个上限的限制，当超过这个限制的时候，索引段可以自动合并成为一个。
> 
> 在同样没有缓存的情况下，一个没有经过优化的索引会被经过优化的索引的性能少10%......
> 
> 自动加热的时间将会变长，因为他依赖于搜索。
> 
> 优化将会对索引的分发产生影响。
> 
> 在优化期间，文件的大小将会是索引的两倍，不过最终将会回到他原来的大小，或者会更小一点。
> 
> 优化，会将所有的索引段合并成为一个索引段，所以，优化这个操作其实可以帮汉族避免“too many files”这个问题，这个错误是由文件系统抛出的。

## Updates and Commit Frequency Tradeoffs ##

> 如果从机经常从主机更新的话，从机的性能是会收到影响的。为了避免，由于这个问题而引起的性能下降，我们还必须了解从机是怎样执行更新的，这样我们才能更准确去调节一些相关的参数（commit的频率，spappullers，autowarming，autocount），这样从机的更新才不会太频繁。
> 
> 1.  执行commit操作会让solr新生成一个snapshot。如果将postCommit参数设成true的话，optiomization也会执行snapShot。
> 2.  slave上的Snappuller程序一般是在crontab上面执行的，他会去master询问，有没有新版的snapshot。一旦发行新的版本，slave就会把他下载下来，然后snapinstall。
> 3.  每次当一个新的searcher被打开的时候，会有一个缓存预热的过程，预热之后，新的索引才会交付使用。
> 
> 这里讨论三个有关的参数：
> 
>  *  **number/frequency of snapshots，**snapshot的频率。
>  *  **snappullers**是在crontab中的，它当然可以每秒一次、每天一次或者其他的时间间隔一次运行。他运行的时候，只会下载slave上没有的，并且最新的版本。
>  *  **Cache autowarming**可以在solrconfig.xml文件配置。

> 如果，你想要的效果是频繁的更新slave上的索引，以便这样看起来比较像“实时索引”。那么，你就需要让snapshot尽可能频繁的运行，然后也让snappuller频繁的运行。这样，我们或许可以每5分钟更新一次，并且还能取得不错的性能，当然，cache的命中率是很重要的，缓存的加热时间也将会影响到更新的频繁都。
> 
> cache对性能是很重要的。一方面，新的缓存必须拥有足够的缓存量，这样接下来的查询才能够从缓存中受益。另一方面，缓存的预热将可能占有很长一段时间，尤其是，他其实是只使用一个线程和一个CPU在工作。snapinstaller太频繁的话，solr slave 将会处于一个不太理想的状态，可能他还在预热一个新的缓存，然而一个更新的searcher被打开了。
> 
> 怎么解决这样的一个问题，我们可能会取消第一个searcher，然后去处理一个更新searcher，也是第二个。然而有可能第二个searcher还没有被使用上的时候，第三个又过来了。一个恶性的循环。当然也有可能，我们刚刚预热好的时候就开始新一轮的缓存预热，其实，这样缓存的作用压根就没有能体现出来。出现这种情况的时候，降低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 UsageConsiderations（内存方面的考虑） ##

### OutOfMemoryErrors ###

> 如果你的solr实例没有被指定足够多的内存的话，java virtual machine 也许会抛出 outofmemoryError，这个并不对索引数据产生影响。但是这个时候，任何的adds/deletes/commits操作都是不能够成功的。

### Memory allocated to the JVM ###

> 最简单的解决这个方法就是，当然前提是java virtual machine 还没有使用掉你全部的内存，增加运行solr的java虚拟机的内存。

> 影响内存使用量的因素，我想，你或许也会考虑怎样去减少solr的内存使用量。其中一个因素就是input document的大小。当我们使用xml执行add操作的时候，就会有两个限制。
> 
>  *  document中的field都是会被存进内存的，field有个属性叫maxFieldLength，他或许能帮上忙。
>  *  每增加一个域，也是会增加内存的使用的。  
>