ApsaraDB for Redis provides efficient database services. Insufficient memory may cause issues such as frequently evicted keys, increased response time, and an unstable number of queries per second (QPS). These issues may disrupt services. When the memory usage exceeds 95%, you must respond in a timely manner.

Step 1: Analyze the memory usage

  1. You can query the information about memory usage during a specified period of time. For more information, see Query monitoring data.

    In this example, the memory usage (indicated by the Memory Usage metric) continuously increases and is about to reach 100%, as shown in the following figure.

    Figure 1. Memory usage example
    Memory usage example
    Note If you select Data Node Aggregation to display memory usage on an instance that uses the cluster architecture or read /write splitting architecture, Memory Usage indicates the average memory usage of all data nodes in the instance, excluding read replica nodes.
  2. Check whether the total number of evicted keys and the maximum command latency are increasing.

    In the following example, the total number of evicted keys and the maximum command latency increased at 16:00:00 (UTC+8) on January 7, 2021. This indicates that the memory resources are insufficient.

    Note The monitoring metrics that need your attention are Evicted Keys (the total number of evicted keys) and Max Rt (the maximum amount of time it takes to return a response after a data node receives a command).
    Figure 2. Performance monitoring example
    Performance monitoring example
  3. Optional:When the memory usage of an ApsaraDB for Redis instance does not meet your expectations, you can perform the following steps to analyze the memory usage in detail.
    Note The major version of your instance must be Redis 4.0 or later if you want to run related commands in this step. For more information about how to upgrade the major version, see Upgrade the major version.
    1. Use redis-cli.
    2. In the Redis command line interface, run the MEMORY STATS command to query detailed information about the memory usage.
      The memory overhead of an ApsaraDB for Redis instance consists of two components:
      • The memory overhead of business data. This is the key component that you need to analyze.
      • The memory overhead of non-business data, such as the backlog buffer of master-replica replication and the memory allocated to initialize the Redis process.

      The following sample response describes the returned parameters:

      Note In the following response, memory values are measured in bytes.
       1) "peak.allocated" //The peak memory that the Redis process has used over its lifetime so far.
       2) (integer) 79492312
       3) "total.allocated" //The total number of bytes that are allocated to run Redis. This is the current total memory usage.
       4) (integer) 79307776
       5) "startup.allocated" //The memory consumed by Redis at startup.
       6) (integer) 45582592
       7) "replication.backlog" //The size of the replication backlog buffer.
       8) (integer) 33554432
       9) "clients.slaves" //The size of read/write buffer in all replica nodes for master-replica replication.
      10) (integer) 17266
      11) "clients.normal" //The size of read/write buffer in other clients except replica nodes.
      12) (integer) 119102
      13) "aof.buffer" //The cache used for append-only file (AOF) persistence and the cache generated during the AOF rewrite operations.
      14) (integer) 0
      15) "db.0"  //The number of databases.
      16) 1) "overhead.hashtable.main" //The total memory usage of the hash table in the current database. This is the memory usage of metadata.
          2) (integer) 144
          3) "overhead.hashtable.expires" //The memory consumed to store expired keys.
          4) (integer) 0
      17) "overhead.total" //value=startup.allocated + replication.backlog + clients.slaves + clients.normal + aof.buffer + db. X.
      18) (integer) 79273616
      19) "keys.count" //The total number of keys in the current instance.
      20) (integer) 2
      21) "keys.bytes-per-key" //The average size of each key in the current ApsaraDB for Redis instance. Formula: (total.allocated-startup.allocated)/keys.count.
      22) (integer) 16862592
      23) "dataset.bytes" //The memory consumed by business data.
      24) (integer) 34160
      25) "dataset.percentage" //The ratio of memory consumed by business data. Formula: dataset.bytes*100/(total.allocated-startup.allocated).
      26) "0.1012892946600914"
      27) "peak.percentage" //The ratio of the current total memory usage to the historical peak. Formula: total.allocated*100/peak.allocated.
      28) "99.767860412597656"
      29) "fragmentation" //The memory fragmentation rate.
      30) "0.45836541056632996"
    3. In the Redis command line interface, run the MEMORY USAGE command to query the memory consumed by specified keys. Unit: bytes.

      Example:

      MEMORY USAGE Key0089393003

      The following information is returned:

      (integer) 1000072
    4. In the Redis command line interface, run the MEMORY DOCTOR command to obtain memory diagnostic suggestions.
      Figure 3. Diagnostic result example
      Diagnostic result example
      After you run the MEMORY DOCTOR command, diagnostic recommendations for ApsaraDB for Redis instances are provided from the following dimensions. You can make optimization decisions based on the diagnostic suggestions.
          int empty = 0;     /* Instance is empty or almost empty. */
          int big_peak = 0;       /* Memory peak is much larger than used mem. */
          int high_frag = 0;      /* High fragmentation. */
          int high_alloc_frag = 0;/* High allocator fragmentation. */
          int high_proc_rss = 0;  /* High process rss overhead. */
          int high_alloc_rss = 0; /* High rss overhead. */
          int big_slave_buf = 0;  /* Slave buffers are too big. */
          int big_client_buf = 0; /* Client buffers are too big. */
          int many_scripts = 0;   /* Script cache has too many scripts. */

Step 2: Optimize memory usage

  1. Check whether the existing keys meet business requirements and clear unnecessary keys in a timely manner.
  2. The cache analytics feature allows you to analyze the distribution of big keys and the time-to-live (TTL) policy of keys. For more information, see Cache analysis.
    1. Check whether proper TTL values are set for keys.
      Note In the following example, no TTL values are set for keys. We recommend that you set proper TTL values on your client to meet business requirements.
      Figure 4. Example of expiration time distribution of keys
      Example of expiration time distribution of keys
    2. Evaluate big keys and split the big keys based on your business requirements.
      Figure 5. Example of big key analytics
      Example of big key analytics
  3. Set a proper eviction policy or modify the value of the maxmemory-policy parameter based on your business requirements. For more information, see Parameters overview.
    Note volatile-lru is the default eviction policy of ApsaraDB for Redis. For more information, see How does ApsaraDB for Redis evict data by default?
  4. Set the frequency of deleting expired keys to a proper value or modify the value of the hz parameter based on your business requirements. For more information, see Change the frequency of background tasks.
    Note We recommend that you set the hz parameter to a value that is smaller than 100. If this value is too large, the CPU usage is affected. You can also set the system to automatically adjust the value if the major version of the instance is Redis 5.0.For more information, see Enable dynamic frequency control for background tasks.
  5. If the memory usage is still high after you perform the preceding steps, you can upgrade the memory capacity of the instance. This improves the performance of the instance. For more information, see Change specifications.
    Note Before you upgrade your instance, you can purchase a pay-as-you-go instance to test whether the specifications to which you want to upgrade meet the requirements of your workloads. You can release it after the test is complete. For more information how to release an instance, see Release an instance.