Merge pull request #298602 from MicrosoftDocs/main

Merged by Learn.Build PR Management system

Author: learn-build-service-prod[bot]

articles/azure-cache-for-redis/TOC.yml

@@ -20,7 +20,7 @@
       - name: Create and manage with Azure PowerShell
         href: /azure/redis/how-to-manage-redis-cache-powershell
       - name: Create and manage with Azure CLI
-        href: /azure/redis/scripts/create-managed-cache
+        href: /azure/redis/scripts/create-manage-cache?pivots=azure-cache-redis
       - name: Create and manage premium cache with Azure CLI
         href: scripts/create-manage-premium-cache-cluster.md
       - name: Create Redis cache - Bicep
@@ -93,7 +93,7 @@
       - name: Overview
         href: cli-samples.md
       - name: Create and manage a cache
-        href: /azure/redis/scripts/create-managed-cache
+        href: /azure/redis/scripts/create-manage-cache?pivots=azure-cache-redis
       - name: Create and manage a premium cache
         href: scripts/create-manage-premium-cache-cluster.md
 
@@ -190,8 +190,6 @@
       href: cache-administration.md#update-channel-and-schedule-updates
     - name: Configure redis-cli access
       href: cache-how-to-redis-cli-tool.md
-    - name: Create and manage a cache using CLI
-      href: cache-manage-cli.md
     - name: Move between regions
       href: cache-moving-resources.md
     - name: Publishing Azure Cache for Redis events

articles/azure-cache-for-redis/cache-best-practices-memory-management.md

@@ -6,49 +6,57 @@ description: Learn how to manage your Azure Cache for Redis memory effectively.
 ms.topic: conceptual
 ms.custom:
   - ignite-2024
-ms.date: 03/22/2022
+ms.date: 04/14/2025
 appliesto:
   - ✅ Azure Cache for Redis
 
 ---
 
 # Memory management
 
-## Eviction policy
+This article describes best practices for memory management in Azure Cache for Redis.
 
-Choose an [eviction policy](https://redis.io/topics/lru-cache) that works for your application. The default policy for Azure Cache for Redis is `volatile-lru`, which means that only keys that have a TTL value set with a command like [EXPIRE](https://redis.io/commands/expire) are eligible for eviction.  If no keys have a TTL value, then the system won't evict any keys.  If you want the system to allow any key to be evicted if under memory pressure, then you may want to consider the `allkeys-lru` policy.
+## Choose the right eviction policy
 
-## Keys expiration
+Choose an [eviction policy](https://redis.io/topics/lru-cache) that works for your application. The default policy for Azure Cache for Redis is `volatile-lru`, which means that only keys that have a time to live (TTL) value set with a command like [EXPIRE](https://redis.io/commands/expire) are eligible for eviction. If no keys have a TTL value, the system doesn't evict any keys. If you want the system to allow any key to be evicted if under memory pressure, consider the `allkeys-lru` policy.
 
-Set an expiration value on your keys. An expiration removes keys proactively instead of waiting until there's memory pressure.  When eviction happens because of memory pressure, it can cause more load on your server. For more information, see the documentation for the [EXPIRE](https://redis.io/commands/expire) and [EXPIREAT](https://redis.io/commands/expireat) commands.
+## Set a keys expiration date
+
+Eviction due to memory pressure can cause more load on your server. Set an expiration value on your keys to remove keys proactively instead of waiting until there's memory pressure. For more information, see the documentation for the Redis [EXPIRE](https://redis.io/commands/expire) and [EXPIREAT](https://redis.io/commands/expireat) commands.
 
 ## Minimize memory fragmentation
 
-Large values can leave memory fragmented on eviction and might lead to high memory usage and server load.
+Large key values can leave memory fragmented on eviction and might lead to high memory usage and server load.
 
 ## Monitor memory usage
 
-Add monitoring on memory usage to ensure that you don't run out of memory and have the chance to scale your cache before seeing issues.
+[Monitor memory usage](/azure/redis/monitor-cache#view-cache-metrics) to ensure that you don't run out of memory. [Create alerts](/azure/redis/monitor-cache#create-alerts) to give you a chance to scale your cache before issues occur.
 
 ## Configure your maxmemory-reserved setting
 
-Configure your [maxmemory-reserved setting](cache-configure.md#memory-policies) to improve system responsiveness:
+Configure your [maxmemory-reserved settings](cache-configure.md#memory-policies) to maximize system responsiveness. Sufficient reservation settings are especially important for write-heavy workloads, or if you're storing values of 100 KB or more in your cache.
+
+- The `maxmemory-reserved` setting configures the amount of memory, in MB per instance in a cluster, reserved for noncache operations such as replication during failover. Setting this value allows you to have a more consistent Redis server experience when your load varies.
+
+- The `maxfragmentationmemory-reserved` setting configures the amount of memory, in MB per instance in a cluster, reserved to accommodate memory fragmentation. When you set this value, the Redis server experience is more consistent when the cache is full or close to full and the fragmentation ratio is high.
 
-- A sufficient reservation setting is especially important for write-heavy workloads or if you're storing values of 100 KB or more in your cache. By default when you create a cache, approximately 10% of the available memory is reserved for `maxmemory-reserved`. Another 10% is reserved for `maxfragmentationmemory-reserved`. You can increase the amount reserved if you have write-heavy loads.
+When memory is reserved for these operations, it's unavailable for storing cached data. By default when you create a cache, approximately 10% of the available memory is reserved for `maxmemory-reserved`, and another 10% is reserved for `maxfragmentationmemory-reserved`. You can increase the amounts reserved if you have write-heavy loads.
 
-- The `maxmemory-reserved` setting configures the amount of memory, in MB per instance in a cluster, that is reserved for non-cache operations, such as replication during failover. Setting this value allows you to have a more consistent Redis server experience when your load varies. This value should be set higher for workloads that write large amounts of data. When memory is reserved for such operations, it's unavailable for storage of cached data. The allowed range for `maxmemory-reserved` is 10% - 60% of `maxmemory`. If you try to set these values lower than 10% or higher than 60%, they are re-evaluated and set to the 10% minimum and 60% maximum. The values are rendered in megabytes.
+The allowed ranges for `maxmemory-reserved` and for `maxfragmentationmemory-reserved` are 10%-60% of `maxmemory`. If you try to set these values lower than 10% or higher than 60%, they're reevaluated and set to the 10% minimum and 60% maximum.
 
-- The `maxfragmentationmemory-reserved` setting configures the amount of memory, in MB per instance in a cluster, that is reserved to accommodate for memory fragmentation. When you set this value, the Redis server experience is more consistent when the cache is full or close to full and the fragmentation ratio is high. When memory is reserved for such operations, it's unavailable for storage of cached data. The allowed range for `maxfragmentationmemory-reserved` is 10% - 60% of `maxmemory`. If you try to set these values lower than 10% or higher than 60%, they are re-evaluated and set to the 10% minimum and 60% maximum. The values are rendered in megabytes.
+When you scale a cache up or down, both `maxmemory-reserved` and `maxfragmentationmemory-reserved` settings automatically scale in proportion to the cache size. For example, if `maxmemory-reserved` is set to 3 GB on a 6-GB cache, and you scale to a 12-GB cache, the setting automatically updates to 6 GB during scaling. If you scale down, the reverse happens.
 
-- One thing to consider when choosing a memory reservation value (`maxmemory-reserved` or `maxfragmentationmemory-reserved`) is how this change might affect a cache with large amounts of data in it that is already running. For instance, if you have a 53-GB cache with with the reserved values set to the minimum of 10 GB, the max available memory for the system is approximately 42 GB. If either your current `used_memory` or your `used_memory_rss` values are higher than the limit of 42 GB, then the system must evict data until both `used_memory` and `used_memory_rss` are below 42 GB. Eviction can increase server load and memory fragmentation. For more information on cache metrics such as `used_memory` and `used_memory_rss`, see [Create your own metrics](../redis/monitor-cache.md#create-your-own-metrics).
+Consider how changing a `maxmemory-reserved` or `maxfragmentationmemory-reserved` memory reservation value might affect a cache with a large amount of data in it that is already running. For instance, if you have a 53-GB cache with the reserved values set to the 10% minimums, the maximum available memory for the system is approximately 42 GB. If either your current `used_memory` or `used_memory_rss` values are higher than 42 GB, the system must evict data until both `used_memory` and `used_memory_rss` are below 42 GB.
+
+Eviction can increase server load and memory fragmentation. For more information on cache metrics such as `used_memory` and `used_memory_rss`, see [Create your own metrics](/azure/redis/monitor-cache#create-your-own-metrics).
 
 > [!NOTE]
-> When you scale a cache up or down, both `maxmemory-reserved` and `maxfragmentationmemory-reserved` settings automatically scale in proportion to the cache size. For example, if `maxmemory-reserved` is set to 3 GB on a 6-GB cache, and you scale to 12-GB cache, the settings automatically get updated to 6 GB during scaling. When you scale down, the reverse happens.
-> When you scale a cache up or down programmatically, using PowerShell, CLI or Rest API, any `maxmemory-reserved` or `maxfragmentationmemory-reserved` are ignored as part of the update request. Only your scaling change is honored. You can update these memory settings after the scaling operation has completed.
+> When you scale a cache up or down programmatically by using Azure PowerShell, Azure CLI, or REST API, any included `maxmemory-reserved` or `maxfragmentationmemory-reserved` settings are ignored as part of the update request. Only your scaling change is honored. You can update the memory settings after the scaling operation completes.
 
-## Next steps
+## Related content
 
+- [Memory policies](cache-configure.md#memory-policies)
+- [Troubleshoot high memory usage](cache-troubleshoot-timeouts.md#high-memory-usage)
+- [Best practices for scaling](cache-best-practices-scale.md)
 - [Best practices for development](cache-best-practices-development.md)
 - [Azure Cache for Redis development FAQs](cache-development-faq.yml)
-- [maxmemory-reserved setting](cache-configure.md#memory-policies)
-- [Best practices for scaling](cache-best-practices-scale.md)