我们有一个在带有 Oracle Java 6 Hotspot JDK 的 Windows 2008 R2 上运行的 Solr 3.4 实例，该实例变得无响应。当我们查看机器时，我们注意到可用物理内存变为零。
Tomcat7.exe 进程使用了约 70Gigs（私有工作集），但工作集（内存）正在使用系统上的所有内存。 Tomcat/Solr 日志中没有错误。我们使用 VMMap 来识别内存用于映射 Solr 段文件的内存。
重新启动 Tomcat 暂时解决了问题，但最终又出现了。
然后，我们尝试减小 JVM 大小，为内存映射文件提供更多空间，但 Solr 最终在老一代达到 100% 时变得无响应。再次重置解决了问题，但在重置之前并没有抛出内存不足异常。
目前我们的敏锐感觉告诉我们，当存在内存压力时，缓存不会收缩，并且可能有太多 MappedByteBuffer 闲置，导致操作系统无法从内存映射文件中释放内存。
参数太多，信息太少，无法帮助解决任何细节。这个答案和提到的系统一样也很古老。
以下是一些对我的经验有帮助的事情：
- 相反，减少 Tomcat 和 SOLR 中的 RAM 使用量，以降低交换风险。给系统留出喘息的空间。
- 如果在 Tomcat 或 SOLR 配置没有任何更改的情况下“开始”出现 - 可能是因为 SOLR 必须索引和查询的数据量增加了。这可能意味着原始配置从一开始就不好，或者已经达到当前资源的限制并且必须进行审查。哪一个？
- 检查查询（如果您可以影响它们）：将经常请求的任何子查询构造移动到过滤器查询中，将非常单独的请求构造移动到常规查询参数中。减少查询缓存，增加/保留过滤器查询缓存 - 或者减少过滤器缓存，以防系统中过滤器查询使用得不多。
- 检查 SOLR 的 schema.xml 中的配置错误（实际上可能只是误解）。我曾经遇到过这个问题：导入字段会被大量创建，导致 RAM 溢出。
- 如果在导入过程中发生这种情况：检查导入过程是否设置为自动提交并经常提交并且也进行优化 - 也许可以减少提交频率并在最后仅优化一次。
- 升级Java、Tomcat和SOLR
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
