Warning: file_get_contents(/data/phpspider/zhask/data//catemap/9/solr/3.json): failed to open stream: No such file or directory in /data/phpspider/zhask/libs/function.php on line 167

Warning: Invalid argument supplied for foreach() in /data/phpspider/zhask/libs/tag.function.php on line 1116

Notice: Undefined index: in /data/phpspider/zhask/libs/function.php on line 180

Warning: array_chunk() expects parameter 1 to be array, null given in /data/phpspider/zhask/libs/function.php on line 181
Java 创建/删除核心时的Solr Permgen异常_Java_Solr_Bitnami_Permgen - Fatal编程技术网

Java 创建/删除核心时的Solr Permgen异常

Java 创建/删除核心时的Solr Permgen异常,java,solr,bitnami,permgen,Java,Solr,Bitnami,Permgen,我们在64位windows安装上使用Solr 4.6.0-1的Bitnami版本,安装64位Java 1.7U51,我们发现PermGen异常存在一致的问题。我们将permgen配置为512MB。Bitnami附带了32位版本的Java for windows,我们正在用64位版本替换它 传入Java选项: -XX:MaxPermSize=512M -Xms3072M -Xmx6144M -XX:+UseParNewGC -XX:+UseConMarkSweepGC -XX:CMSInitiat

我们在64位windows安装上使用Solr 4.6.0-1的Bitnami版本,安装64位Java 1.7U51,我们发现PermGen异常存在一致的问题。我们将permgen配置为512MB。Bitnami附带了32位版本的Java for windows,我们正在用64位版本替换它

传入Java选项:

-XX:MaxPermSize=512M -Xms3072M -Xmx6144M -XX:+UseParNewGC -XX:+UseConMarkSweepGC -XX:CMSInitiatingOccupancyFraction=75 -XX:+CMSClassUnloadingEnabled -XX:NewRatio=3

-XX:MaxTenuringThreshold=8

这是我们的用例:

我们有一个数据库核心,它保持相当静态,包含从SQLServer导入的表内容。然后,我们有用户核心,其中包含Solr之外的文本搜索结果的记录ID。然后,我们从数据库核心查询所需的数据,并将结果限制在用户核心的内容内。这允许我们将来自Solr的方面数据与来自另一个引擎的搜索结果相结合。我们正在按需创建用户核心,并在用户注销时删除它们

我们的问题是不断地创建和删除用户核心,再加上不断地导入,似乎将我们推到了永久极限之上。在每个会话结束时删除用户核心,作为测试,我制作了一个应用程序,该应用程序将循环创建用户核心,向其导入一组数据,将其用作限制器查询数据库核心,然后删除用户核心。我的期望是,在这种情况下,与该用户核心相关的所有permgen都将在卸载时释放,并允许permgen在垃圾收集期间回收该内存。情况并非如此,它将不断上升,直到应用程序耗尽内存

我还调查了两个内核之间是否存在连接,因为我在一个查询中将它们连接在一起,但即使在卸载所有用户内核后卸载数据库内核,也不会阻止达到限制或从Solr垃圾收集任何内存

这是创建和卸载大量内核的已知问题吗?它是否可以基于核心的配置?除了卸载之外,是否还需要进行其他操作来释放引用

谢谢

注:
我尝试使用工具来确定它是否是Solr内部的泄漏,例如水管工,但我的活动没有发现任何问题。

这似乎是Solr本身的问题。我们正在组装一个包含测试用例的包,希望在将来的版本中修复它。与此同时,我们让用户核心成为按需创建的静态对象,这似乎缓解了问题,我们可以每周重置一次实例,使其不发生。

我不明白的是,您说我们将permgen配置为512MB,但您写的Java参数是-XX:MaxPermSize=64M。这不合适…这是我的错,我从一个solr实例复制了配置,我用它来运行测试以检查垃圾收集。有问题的实际部署是512M,我已经更新了问题以反映这一点。谢谢