我有一个包含10个字段的Lucene.net索引，其中一些是存储的，一些是索引的，有4.6亿个文档。该指数约为250GB。我正在使用Lucene.net 3.0.3并且每次进行搜索时我都会在RAM中轻松吃掉2GB +，这会导致我的32位应用程序出现内存异常。遗憾的是，由于其他32位依赖项，我无法将应用程序作为64位进程运行。
据我所知，我正在遵循Lucene的最佳实践：
一个批量编写文档的开放式索引编写器
不会在搜索中关闭并重新打开的共享阅读器
索引搜索者将termInfosIndexDivisor设置为4，这似乎没有什么区别。我甚至尝试将它设置为像1000这样大的东西，但没有注意到任何记忆变化。
不分析不需要进行子搜索的字段（即仅完整字符串搜索），并且不存储不需要从搜索中检索回的字段。
我正在使用默认的StandardAnalyzer进行索引和搜索。
如果我修剪数据并制作一个较小的索引，那么事情就可以了。当我的索引大小约为50GB时，我只能用大约600MB的RAM进行搜索
但是，我确实在其中一个字段上应用了排序，但即使没有排序，任何搜索的内存使用量都很大。我并不特别关心文档分数，更多的是文档存在于我的索引中，但我不确定是否忽略分数计算将有助于内存使用。
我最近从Lucene.net 2.9.4升级到Lucene.net 3.0.3，认为这可能会有所帮助，但两个版本之间的内存使用情况大致相同。
坦率地说，我不确定这个索引是否太大，以至于单个机器无法进行搜索。我发现的大多数例子都是关于20-30GB大小或更小的索引，所以也许这是不可能的，但我想至少问一下。
如果有人对我能做什么做任何建议，以使这个可用，这将是伟大的。如果可能的话，我愿意牺牲搜索速度来使用内存。
答案 0 :(得分：5)
您可以以64位运行应用程序 - 为lucene部分创建单独的进程，使用远程处理与它（或WCF）进行通信。成品。标准方法。
你想要拆分它，所以哎呀，隔离它并把它放在64位上。