0

I'm running into this error on my Sitecore prod CD instance, as well as its failover:

ERR Error running script (call to f_f61bd104cdd24acf438fe02407a37f4334659383): @user_script:4: @user_script: 4: -OOM command not allowed when used memory > 'maxmemory'.   
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: StackExchange.Redis.RedisServerException: ERR Error running script (call to f_f61bd104cdd24acf438fe02407a37f4334659383): @user_script:4: @user_script: 4: -OOM command not allowed when used memory > 'maxmemory'. 

I saw this article pop up, which was mostly about monitoring: Sitecore fails when memory > maxmemory in Redis. At the moment our prod instances are in development and we're building them out, so there's no traffic to speak of. When we spun up the failover instance, originally both were pointing to the same Redis cache, but I created a failover one and changed the connection string to separate them. Now after a deployment, the message returned.

We were using the basic 1GB tier, which we're updating to C2 now, but beyond that, is there any way to better manage this? Also, what is the Redis cache really used for, and is there a benefit to it or could we turn it off if it's being an impediment?

1
  • The redis cache is used for session data. If the memory used is truly that high then you may need to scale up. Sitecore can store a very high amount of data in redis if you don’t tune it. However based on your description it’s hard to say for sure.
    – jrap
    Jan 17, 2021 at 2:48

1 Answer 1

1

Ken, good question. Sitecore maintains an ASP.NET Session state outside the process to share between CDs (in fact 2 session states).

The session state is used to flush Analytics data to xDB on Session End.

The problem, thought, only InProc ASP.NET provider supports/raises the event OOB.

Therefore Sitecore had to cook their own providers.

Point 1: do you use Sitecore Redis Session State providers or native StackExchange? It must be Sitecore one, or else nobody would kick out expired sessions and you'll run out of memory.

Point 2: Sitecore mechanism periodically tries to find outdated sessions, and commit them to xDB. The frequency is controlled by polling group. Do you have it set on at least one of the CD servers? If no, again, nobody transfers data.

Point 3: Even though Sitecore gives a guide to estimate record sizes, that could be miles away from truth in the field. Follow the steps to locate real record sizes and config-based instructions there.

Point 4: Sitecore is vulnerable to session state hammering, ensure to set aspnet:RequestQueueLimitPerSession as per KB.

Point 5: Sitecore 10 promises to reduce Analytics size in memory (ref. 384856)

1
  • Thanks Nikolay, and welcome! Good stuff to look over. Sitecore support also suggested keeping the session state at 20, and maybe increasing the pollingInterval to 30. These are good resources to review the situation as well. Jan 23, 2021 at 10:48

Your Answer

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

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