General best practices

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

For a list of troubleshooting scenarios, see Troubleshooting.

RDB exporting

When exporting a RDB backup use the following guidance:

Resource-intensive operations

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

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

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

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

  • Lower the maxmemory config 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 these operations.
  • Run these operations during periods of low instance traffic (such as overnight, or over the weekend, etc.).
  • Have retry logic with exponential backoff in place before running these operations.

Operations and scenarios that require a connection retry

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

These operations modify your instance, requiring a temporary connection break. You need to have retry logic with exponential backoff in place before running these operations so that your application automatically reconnects and continues to function normally.

Routine maintenance

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

Implement the following best practices so you are prepared for routine maintenance:

Memory management

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

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

Managing idle connections

Over time, you may see the number of connections to your Memorystore instance increase if connections are not being properly terminated. This can have negative performance implications, especially if you are using in-transit encryption, which imposes maximum connections limits based on your capacity tier. To mitigate this, we recommend utilizing the timeout Redis configuration parameter which allows you to set the number of seconds before idle client connections are automatically terminated.

Access Transparency resource names

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

Serverless VPC Access Connector required for some serverless environments

Some serverless environments require a Serverless VPC Access Connector in order to connect to Memorystore for Redis. Set up the Serverless VPC Access connector for your project if you want to connect using one of these environments.

Networking

We recommend that you use the private services access connection mode. Memorystore for Redis uses two connection modes: private services access and direct peering. The private services access connection mode makes IP range management 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, see Networking.

Monitoring and alerts

We recommend using monitoring and alerts because 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 to incoming cache requests.

You should set up the following default alerts:

CPU usage best practices

The improper use of expensive redis commands leads to high latency, unresponsiveness, or connectivity issues. Standard Tier instances provide high availability during disaster recovery and rely on asynchronous replication between primary and replica nodes. If one of the nodes has an expensive command processing that blocks the Redis main thread, replication could be impacted. If the issue persists and a location outage happens, the most recent data written in the location of the outage might not be available in the other location.

We recommend using Cloud Monitoring to set alerts for the Main Thread CPU Seconds (redis.googleapis.com/stats/cpu_utilization_main_thread) metric to make sure CPU utilization doesn't exceed 0.9 seconds for the primary node and 0.5 seconds for each replica node.

If your Redis instance exceeds the recommended values, we recommend you scale the instance to a higher capacity tier or follow the troubleshooting instructions to avoid CPU intensive operations.