This page provides guidance on optimally using Memorystore for Redis. Thispage also points out potential issues to avoid.

For a list of troubleshooting scenarios, seeTroubleshooting.

RDB exporting

When exporting a RDB backup use the following guidance:

• Export during a period of low write-rate.
• If exporting during a period of high write-rate,temporarily lowermaxmemory config to 50%of the instance capacity to provide sufficient overhead for a successfuloperation.

Resource-intensive operations

For Standard Tier Redis instances, the following operations use extra memory forthe duration of the operation:

• Version upgrade
• Scaling up/down
• Manual failover
• Import / export

Version upgrade, scaling, and manual failover use extra memory (for StandardTier instances) due to replication. These operations follow the replicationprocess described inStandard Tier instance upgrade behavior.

Import and export operations require extra memory because of the forked Redisprocess and copy-on-write data management associated with these operations.

In order to mitigate the drawbacks of resource-intensive operations, you should:

• Lower themaxmemoryconfig to 80% of the instance capacity for the duration of the operation.This provides sufficient overhead for a successful operation.
• Monitor the system memory usage ratio metric,and ensure that this metric is under 80% before running one of theseoperations.
• Run these operations during periods of low instance traffic (such as overnight,or over the weekend, etc.).
• Have retry logic with exponential backoffin place before running these operations.

Operations and scenarios that require a connection retry

The following operations and scenarios break the network connection between yournetwork and the Redis instance:

• Version upgrade
• Scaling up/down
• Importing
• Manual failover
• System maintenance
• Certificate Authority rotationfor Redis instances that havein-transit encryptionenabled
• Emergency failover

These operations modify your instance, requiring a temporary connection break.You need tohave retry logic with exponential backoffin place before running these operations so that your application automaticallyreconnects and continues to function normally.

Routine maintenance

Memorystore for Redis instances undergo maintenance periodically. For more details, see the Memorystore for Redismaintenance policy.

Implement the following best practices so you are prepared for routinemaintenance:

• Set a maintenance window for when maintenance updates can occur.
  • Schedule maintenance windows for times of low instance traffic andsufficient memory overhead. For more information, seeImpacts of maintenance updates.
• Turn on maintenance windows notificationsto alert you of upcoming maintenance.
• Have retry logic with exponential backoffin place.
• For Standard Tier instances you can simulate a maintenance event by usingmanual failoverto see how the failover caused by maintenance affects your application.
• For Basic Tier instances you can simulate the impact of a maintenance updateby temporarilyscalingthe instance to a larger size. After you observe the impact you can scale backto the original size.

Memory management

Memory management can be a challenge because of the well knownmemory fragmentation that occurs with open source Redis. We recommend that you lower themaxmemoryconfiguration for your instance to give yourself overhead in the case of highmemory pressure.

The best way to monitor the memory pressure on your Memorystoreinstance is byusing the System Memory Usage Ratio metric.For more a detailed guide on how to manage memory for Memorystore for Redis,seeMemory management best practices.

Managing idle connections

Over time, you may see the number of connections to your Memorystoreinstance increase if connections are not being properly terminated. This canhave negative performance implications, especially if you are using in-transit encryption, whichimposes maximum connections limitsbased on your capacity tier. To mitigate this, we recommend utilizing thetimeoutRedis configuration parameterwhich allows you to set the number of seconds before idle client connections areautomatically terminated.

Access Transparency resource names

Sensitive data shouldn't be stored in Memorystore for Redis resource names. Byresource names, we mean Memorystore for Redis instance names, and instancemetadata, such as tags. Data stored in resource names is not guaranteed to beprotected by Google CloudAccess Transparency,and may conflict with your organization's Access Transparency compliance requirements.

Serverless VPC Access Connector required for some serverless environments

Some serverless environmentsrequire aServerless VPC Access Connectorin order to connect to Memorystore for Redis. Set up the Serverless VPC Accessconnector for your project if you want to connect using one of theseenvironments.

Networking

We recommend that you use theprivate services accessconnection mode.Memorystore for Redis uses two connection modes: private services access anddirect peering. The private services access connection mode makes IP rangemanagement more simple and allows you to use Shared VPC if you want.

Once you have created an instance, the connection mode cannot be changed.

For more details, seeNetworking.

Monitoring and alerts

We recommend usingmonitoringandalertsbecause they give you key signals on the memory usage of your Redis instance.They also give you insight into how efficiently your Redis instance responds toincoming cache requests.

You should set up the following default alerts:

• Setting a Cloud Monitoring alert for memory usage
• Setting a Cloud Monitoring alert for System Memory Usage Ratio

CPU usage best practices

Theimproper use of expensive redis commandsleads to high latency, unresponsiveness, or connectivity issues. Standard Tierinstances provide high availability during disaster recovery and rely onasynchronous replication between primary and replica nodes. If one of the nodeshas an expensive command processing that blocks the Redis main thread,replication could be impacted. If the issue persists and a location outagehappens, the most recent data written in the location of the outage might not beavailable in the other location.

We recommendusing Cloud Monitoringto set alerts for theMain Thread CPU Seconds(redis.googleapis.com/stats/cpu_utilization_main_thread) metric to make sureCPU utilization doesn't exceed 0.8 seconds for the primary node or 0.5 secondsfor each replica node, when the replica is designated as aread replica.

If your Redis instance exceeds the recommended values, we recommend youscalethe instance to a highercapacity tieror follow thetroubleshooting instructionsto avoid CPU intensive operations.

Resource-intensive commands

We strongly recommend that you avoid using Redis commands that areresource-intensive. Using these commands might result in the followingperformance issues:

• High latency and client timeouts
• Memory pressure caused by commands that increase memory usage
• Data loss during node replication and synchronization because the Redis mainthread is blocked
• Starved health checks, observability, and replication

Tip: In addition to being resource-intensive, asyour total data size increases, so does the cost of using these commands. Tofind which long-running commands you use, useSLOWLOG. This tool provides you with a list ofcommands that take the longest to run. As a result, you know the commands thatcause latency issues.