nva*_*ada 6 lucene garbage-collection solr ehcache
我们正在实施一个包含超过1.5亿文档的大型Lucene/Solr设置.我们每天还会有适量的文档更新.
我的问题实际上是一个两部分:
在Solr中使用另一个缓存实现有什么含义,即EHCache而不是本机Solr LRUCache/FastLRUCache？
Terracotta宣布BigMemory与EHCache一起用作进程内堆外缓存.根据TC,这允许您存储大量数据,而无需JVM的GC开销.与Solr一起使用是个好主意吗？它真的会有帮助吗？
我会特别的.喜欢听到有EHCache/BigMemory和/或Solr Cache调优的真实制作经验的人.
关于这个话题的很多想法.虽然我的回答没有以任何方式利用EhCache.
首先,我不认为文档应存储在您的搜索索引中.搜索内容应存储在那里,而不是整个文档.我的意思是,从搜索查询返回的内容应该是文档ID.不是文件本身的内容.应该从第二个系统存储和检索文档本身,可能是它们从中开始索引的原始文件存储.这将减少索引大小,减少文档缓存大小,减少主从复制时间(如果经常更新,这可能会成为瓶颈),并减少编写搜索响应的开销.
接下来,考虑在Solr前放置一个反向HTTP代理.尽管查询缓存允许Solr快速响应,但像Solr前面的Varnish缓存更快.这会卸载Solr,允许它花时间回复以前从未见过的查询.第二个影响是,您现在可以将大部分内存放在文档缓存而不是查询缓存中.如果您遵循我的第一个建议,您的文档将非常小,允许您保留大部分内容(如果不是全部内容).
快速回退文档大小的包络计算.我可以轻松地提供32位int作为1.5亿个文档的ID.我仍然有10倍的空间用于文档增长.1.5亿个ID占用600MB.为Solr包装文档添加一个软糖因子,您可以轻松地将所有Solr文档缓存在1-2GB中.考虑到现在容易获得12GB-24GB或RAM,我想你可以在1盒上做到这一点,并获得令人难以置信的性能.不需要任何像EhCache那样无关紧要的东西.只是要确保尽可能高效地使用搜索索引.
关于GC:我没有在我的Solr服务器上看到很多GC时间.需要收集的大部分内容是涉及HTTP请求和响应周期的非常短暂的对象,它们永远不会离开伊甸园空间.正确调整后,缓存的周转率不高.唯一的大变化是加载了新索引并刷新了缓存,但这种情况并未持续发生.
编辑:为了背景,我花了一些相当长的时间为一家大型公司调整Solr缓存,该公司销售控制台并每天从其Solr服务器提供数百万次搜索.