12

My website went down last night and as we were looking through the log files on one of the CD instances we found this error:

> 6684 23:20:21 ERROR <?xml version="1.0" encoding="UTF-8"?> <response>
> <lst name="error"><str name="msg">java.lang.OutOfMemoryError: Java
> heap space</str><str name="trace">java.lang.RuntimeException:
> java.lang.OutOfMemoryError: Java heap space   at
> org.apache.solr.servlet.HttpSolrCall.sendError(HttpSolrCall.java:611)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:472)
>   at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:223)
>   at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:181)
>   at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
>   at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
>   at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
>   at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
>   at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
>   at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
>   at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
>   at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
>   at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>   at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
>   at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
>   at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
>   at org.eclipse.jetty.server.Server.handle(Server.java:499)  at
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)     at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
>   at
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
>   at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
>   at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
>   at java.lang.Thread.run(Unknown Source) Caused by:
> java.lang.OutOfMemoryError: Java heap space   at
> java.lang.Class.getEnclosingMethod0(Native Method)    at
> java.lang.Class.getEnclosingMethodInfo(Unknown Source)    at
> java.lang.Class.getEnclosingClass(Unknown Source)     at
> java.lang.Class.getSimpleBinaryName(Unknown Source)   at
> java.lang.Class.getSimpleName(Unknown Source)     at
> org.apache.solr.request.SolrQueryRequestBase.toString(SolrQueryRequestBase.java:170)
>   at
> org.apache.solr.search.stats.LocalStatsCache.get(LocalStatsCache.java:42)
>   at
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:372)
>   at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:273)
>   at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:156)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2073)    at
> org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:658)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:457)
>   at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:223)
>   at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:181)
>   at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
>   at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
>   at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
>   at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
>   at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
>   at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
>   at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
>   at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
>   at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>   at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
>   at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
>   at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
>   at org.eclipse.jetty.server.Server.handle(Server.java:499)  at
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)     at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
>   at
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
> </str><int name="code">500</int></lst> </response>

In looking at the Solr JVM, we noticed that it defaults to a maximum memory of 512 Mb. This does not appear to be enough. We bumped it up to 1 Gig, and that brought up our website and we are not getting any errors in the Solr logs. So what kind of memory footprint are people giving to Solr? What is Sitecore doing that is filling up that much memory?

Improve this question

4 Answers 4

Reset to default
9

There is no one good answer for your question.

I remember we had similar issue few years ago and at that time the answer from one of the Sitecore Solr experts was to start with defaults and observe.

If you encounter any memory issues, double what you assigned. If you have problem again, repeat the step.

There are drawbacks of assigning to much memory so don't go for maximum what your machine has.

Remember that in some scenarios you will have to use 64bit java to be able to assign enough memory.

And your question about what Sitecore does - hard to tell. My guess would be content of media items. In some scenarios Sitecore keeps separate document with all the content of the document for every single language version you have in your solution.

Improve this answer
4

What's the capacity of the server? A rule of thumb would be 1/4 of the available memory . . . so an 8 GB machine could use 2 GB. This is just a rough guide I've seen in a few cases.

Improve this answer
4

I think the answer to this question depends on a number of things:

  1. How many items are in your indexes?
  2. How many indexes do you have and how large are they?
  3. How heavily you are using the indexes?
  4. How much memory you have available on your server and if the server is just a search server or if it provides other services?

With 3) above you need to consider if you are using Content Search a lot in your custom code to get items etc or just really for search results pages only. Also are you using a lot of facets? All of this will lead to more load on the SOLR server.

Based on all of the above you should be able to work out a good amount of Memory to allocate. In my experience the more you allocate the better. I've seen 60% allocation on a dedicated Solr server working well. So on a 16GB server something like 6-12GB seems about right.

However if you have lots of indexes or some are large you may benefit from Sharding your indexes or using Solr Cloud (a good article I've used when setting this up before: http://www.chrissulham.com/sitecore-on-solr-cloud-part-2/)

Improve this answer
1
4

There are a number of factors to this. If yoiu want to calculate the MAXIMUM you should allocate to the JVM on a dedicate Solr box running windows, I would say Floor((Machine memory - 1 GB) / 2) is a good approximation. THe formular says to leave a Gig of memory for the os - and for the rest leave 50% of the remaining for OS disk file cache and the other 50% for the JVM.

As far as I can see in the exception you put in the question, the OOM exception was just due to not having enough memory for the search operation and saving the statistics for it - so not even something which is expected to use a lot of memory.

The best running scenario would be if you have indexsize+2 GB of memory - meaning you can keep all the index in the JVM memory and some for OS etc. If you have this you can assign more memory to the JVM as the OS disk cache is not important then - but index changes are expensive then.

if you have large analytics indexes (sitecore 8+) your memory consumption will rise quite a lot due to a high amount of index writes and commits.

the golden rule of Solr and memory is "as much as you can afford...."

Improve this answer
2
  • Hi Klaus, The problem with your statement is that our Analytics index on disk is over 100 Gigs, and I can't convince my server team that I'm going to need 102 Gigs of Ram, and it will need to consistently grow for eternity. :) So that's why I was asking about the required specs for the system. I appreciate your answer, and would love some additional feedback if you have it.
    – Keith VanderVeen
    Nov 22, 2017 at 21:15
  • yeah - the analytics index should not have that much - it is not used extensively for quering - so I would probably leave it at 16 GB or so.
    – Klaus Petersen
    Nov 23, 2017 at 22:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.