We are using Sitecore 9 Update 2 and SXA 1.7.1 in azure PaaS. We are facing issues with Redis cache. The website suddenly throws below error when we looked at Redis cache usage in Azure it's showing as always 100MB .

We tried to flush memory that did not work out either any clues on this error


Timeout performing EVAL, inst: 0, mgr: Inactive, err: never, queue: 26953, qu: 26953, L75: 0, qc: 0, wr: 0, wq: 0, in: 0, ar: 0,IOCP: Busy=0,Free=1000,Min=2,MaX=1000), WORKER: (Busy=2,Free=32765,Min=50,MaX=32767)

Stack Trace:

[TimeoutException: Timeout performing EVAL, inst: 0, mgr: Inactive, err: never, queue: 26953, qu: 26953, qs: 6, qc: 8, wr: 6, wq: 6, in:

9, ar: 9, IOCP: (StackExchange.Redis.ConnectionMu1tiplexer.ExecuteSyncImpl(Message message, ResultProcessor‘1 processor, ServerEndPoint server) +661
StackExchange.Redis.RedisBase.ExecuteSync(Message message, Resu1tProcessor\1 processor, ServerEndPoint server) +122
StackExchange.Redis.RedisDatabase.ScriptEvaluate(String script, RedisKey[] keys, RedisValue[] values, CommandFlags flags) +141

.Redisconnectionwrapper.TryTakewriteLockAndGetData(String sessionld, DateTime lockTime, 0bject& 1ockId, Isessionstatelten
StackExchangeclientconnection.RetryForScriptNotFound(Func‘1 redisoperation) +146
StackExchangeclientconnection.RetryLogic(Func‘1 redisoperation) +159
StackExchangeclientconnection.Eval(String script, String[] keyArgs, Object[] va1ueArgs) +669

RedissessionStateProvider.GetItemFromSessionStore(Boolean iswriteLockRequired, Httpcontext context, String id, Boo1ean&
RedisSessionStateProvider.GetItemExclusive(Httpcontext context, String id, Boo1ean& locked, TimeSpan& lockAge, Object& J

System.web.SessionstateiSessionStateModule.GetSessionStateItem() +169

It's not entirely clear if this is happening under load, but there are a number of troubleshooting steps and configuration changes you can make to optimise your Sitecore implementation with Redis. The out of the box settings often need some tweaking depending on your environment.

  1. Confirm the Redis cache is not under too much load. You should be able to view all the relevant metrics in Azure portal. In this case look at Memory usage (as you've already done), Load, CPU and Network Bandwidth. This may show indicators of the bottleneck. If any of these are maxing out, then you will need to scale up.

  2. Ensure you're not inadvertently storing/retrieving large objects into/from session in your custom code. This can cause significant overheads on both the CD and Redis, perhaps look at other architectural options if this is the case.

  3. Confirm Redis Azure cache is in the same region as your CD instances. Latency is your enemy with Redis. Having it in the same region and running on an SKU with "High"+ Network performance will help.

  4. Sitecore offer some guidance on optimising solutions using Redis to avoid timeouts. This includes a patch and configuration settings that change the Redis timeout settings. As with all patches, you should confirm it's appropriateness for your solution with Support before applying it. https://kb.sitecore.net/articles/464570

  5. Split your shared and private session repositories onto two Redis instances. Obviously this would incur additional cost, but if it's truly under load may be a good option. To do this you'll need to create a new Redis instance, add the connection string to ConnectionStrings.config then patch in the new connection string name to shared session config.

You can find more details in the documentation in the "Configure Sitecore" section at: https://doc.sitecore.com/developers/90/platform-administration-and-architecture/en/walkthrough--configuring-a-shared-session-state-database-using-the-redis-provider.html The endstate of your shared session config on the CD (patching over the original config in Sitecore.Analytics.Tracking.config) would look something like this:

<sharedSessionState defaultProvider="redis">
        <add name="redis"

Also have a read of the following blog from Gabe Streza: https://www.sitecoregabe.com/2019/02/redis-dead-redemption-redis-cache.html . While it may not be the exact same symptoms or root issue, there are some good insights into troubleshooting and resolutions.

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