Question

我们在使用以下参数在4.6.0版上运行的Solr部署时遇到问题：

java -Xss256k -Xms512m -Xmx30g -jar start.jar

Solr在Windows Server 2008 R2上运行，内存为64GB RAM＆amp; 12核心。 30 GB分配给Solr实例，数据导入后的索引大小约为。 1.2 GB。启动Solr实例后，Solr仪表板上的JVM内存使用情况显示：

Used Memory: 8.61 GB
Peak Memory: 15.19 GB
Total Memory: 29.02 GB

几天后，我们注意到内存读起来像

Used Memory: 22.32 GB
Peak Memory: 29.02 GB
Total Memory: 29.02 GB

索引每小时刷新一次（凌晨2点至凌晨4点除外）＆amp;它们的尺寸几乎没有太大变化。

但是，经过一段时间后，索尔似乎变得反应迟钝。 Solr仪表板无法加载，查询失败会给出如下所示的错误。我们搜索了很多，似乎无法找到任何解决方案。唯一的临时解决方法是在java进程超过30 GB的内存使用量时重新启动Solr实例。此后它运行良好约10-12天，但同样的问题再次出现。

以下给出的错误每天发生，大多在上午12点到早上6点之间。但是，在此期间，流量非常少。也没有Solr核心在凌晨2点到凌晨4点之间重新编制索引，因为在此期间没有数据变化。

我们在jetty.xml中更改了以下几个配置，但是，这似乎也没什么帮助。

<Set name="maxIdleTime">1200000</Set>
<Set name="lowResourceMaxIdleTime">10000</Set>

ERROR - 2015-12-04 02:10:56.821; org.apache.solr.common.SolrException; null:org.eclipse.jetty.io.EofException 
at org.eclipse.jetty.http.HttpGenerator.flushBuffer(HttpGenerator.java:914) 
at org.eclipse.jetty.http.AbstractGenerator.blockForOutput(AbstractGenerator.java:507) 
at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:147) 
at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:107) 
at sun.nio.cs.StreamEncoder.writeBytes(Unknown Source) 
at sun.nio.cs.StreamEncoder.implWrite(Unknown Source) 
at sun.nio.cs.StreamEncoder.write(Unknown Source) 
at java.io.OutputStreamWriter.write(Unknown Source) 
at org.apache.solr.util.FastWriter.flush(FastWriter.java:141) 
at org.apache.solr.util.FastWriter.write(FastWriter.java:55) 
at org.apache.solr.response.JSONWriter.writeStr(JSONResponseWriter.java:449) 
at org.apache.solr.response.JSONWriter.writeKey(JSONResponseWriter.java:103) 
at org.apache.solr.response.JSONWriter.writeSolrDocument(JSONResponseWriter.java:346) 
at org.apache.solr.response.TextResponseWriter.writeDocuments(TextResponseWriter.java:275) 
at org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:172) 
at org.apache.solr.response.JSONWriter.writeNamedListAsMapWithDups(JSONResponseWriter.java:183) 
at org.apache.solr.response.JSONWriter.writeNamedList(JSONResponseWriter.java:299) 
at org.apache.solr.response.JSONWriter.writeResponse(JSONResponseWriter.java:95) 
at org.apache.solr.response.JSONResponseWriter.write(JSONResponseWriter.java:60) 
at org.apache.solr.servlet.SolrDispatchFilter.writeResponse(SolrDispatchFilter.java:698) 
at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:426) 
at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:197) 
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419) 
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455) 
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137) 
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557) 
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231) 
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075) 
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384) 
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193) 
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009) 
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135) 
at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255) 
at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154) 
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116) 
at org.eclipse.jetty.server.Server.handle(Server.java:368) 
at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489) 
at org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53) 
at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942) 
at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004) 
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640) 
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235) 
at org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72) 
at org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264) 
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608) 
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543) 
at java.lang.Thread.run(Unknown Source) 

Caused by: java.net.SocketException: Software caused connection abort: socket write error 
at java.net.SocketOutputStream.socketWrite0(Native Method) 
at java.net.SocketOutputStream.socketWrite(Unknown Source) 
at java.net.SocketOutputStream.write(Unknown Source) 
at org.eclipse.jetty.io.ByteArrayBuffer.writeTo(ByteArrayBuffer.java:375) 
at org.eclipse.jetty.io.bio.StreamEndPoint.flush(StreamEndPoint.java:164) 
at org.eclipse.jetty.io.bio.StreamEndPoint.flush(StreamEndPoint.java:182) 
at org.eclipse.jetty.http.HttpGenerator.flushBuffer(HttpGenerator.java:838)

Answer 1

如果solr和Java版本分别为> 5.5和> 1.8.0_5，我建议在ConcurrentMarkSweep上为solr配置G1GC。

要配置G1GC，请遵循以下参数

GC_TUNE =“-XX：+ UseG1GC -XX：+ PerfDisableSharedMem -XX：+ ParallelRefProcEnabled -XX：+ UnlockExperimentalVMOptions -XX：G1HeapRegionSize = 32m -XX：MaxGCPauseMillis = 500 -XX：G1NewSizePercent = 5 -XX：G1MaxNewSizePercent -XX：正在启动HeapOccupancyPercent = 45 -XX：G1MixedGCLiveThresholdPercent = 65 -XX：+ UseLargePages -XX：+ AggressiveOpts“

Answer 2

根据我的经验，渐渐无反应可能是调整不佳的JVM的症状。我建议使用带有VisualGC插件的VisualVM等工具监视JVM，或者将GC记录到文件中并使用许多可用工具之一进行分析。

来自维基：

https://wiki.apache.org/solr/SolrPerformanceProblems

当你有一个大堆（大于2GB）时，垃圾收集暂停可能是一个主要问题。这通常是偶尔造成的需要完整的垃圾收集，必须“停止世界”＃34; - 停顿所有程序执行以清理内存。主要有两个解决方案：一个是使用像Zing这样的商业低暂停JVM 确实带有价格标签。另一个是调整您自由的JVM 已经有了。 GC调整是一种艺术形式，适用于一个人可能不适合你。

除非你看起来很好，否则很难确切知道。考虑到堆的大小，您可能需要尝试使用常用参数（如NewSize）或使用收集算法（例如，ConcurrentMarkSweep可用于最小化暂停）。

Solr和JVM内存管理问题

2 个答案: