我们在64位Java 1.7U51的64位Windows安装上使用了Solr 4.6.0-1的Bitnami版本，我们看到了PermGen异常的一致问题。我们将permgen配置为512MB。 Bitnami为Windows提供了32位版本的Java，我们正在用64位版本替换它。
在Java选项中传递：
-XX：MaxPermSize参数= 512M
-Xms3072M
-Xmx6144M
-XX：+ UseParNewGC
-XX：+ UseConcMarkSweepGC
-XX：CMSInitiatingOccupancyFraction = 75
-XX：+ CMSClassUnloadingEnabled
-XX：NewRatio = 3
-XX：MaxTenuringThreshold = 8
这是我们的用例：
我们称之为数据库核心，它保持相当静态，并包含SQL服务器中表的导入内容。然后，我们有用户核心，其中包含来自Solr之外的文本搜索的结果的记录ID。然后，我们从数据库核心查询我们想要的数据，并将结果限制为用户核心的内容。这允许我们将来自Solr的facet数据与来自另一个引擎的搜索结果相结合。我们按需创建用户核心，并在用户注销时删除它们。
我们的问题是不断创建和删除用户核心以及持续导入似乎会让我们超越我们的PermGen限制。在每个会话结束时删除用户核心并作为测试我创建了一个应用程序，它将循环创建用户核心，向其导入一组数据，使用它作为限制器查询数据库核心，然后删除用户核心。我的期望是在这种情况下，与该用户核心相关联的所有permgen将在卸载时释放，并允许permgen在垃圾收集期间回收该内存。情况并非如此，它会不断上升，直到应用程序耗尽内存。
我还调查了两个核心之间是否存在连接因为我在查询中将它们连接在一起但是在卸载所有用户核心之后甚至卸载数据库核心也不会阻止限制被攻击或任何内存是从Solr收集的垃圾。
这是创建和卸载大量内核的已知问题吗？它可能是基于核心的配置吗？除了卸载之外还有什么东西可以用来释放引用吗？
由于
注意： 我已经尝试使用工具来确定Solr中是否存在泄漏，例如Plumbr，我的活动一无所获。
答案 0 :(得分：0)
这看起来像是Solr本身的一个问题。我们正在整理一个包含测试用例的软件包，并希望在将来的版本中修复它。与此同时，我们使用户核心是按需创建的静态对象，这似乎可以将问题缓解为我们可以每周重置一次实例而不会发生的问题。