Redis Memory Test

Like CPU resources, the Redis server has to be sized with adequate memory resources as well to achieve optimal performance. Excessive memory usage can cause significant deterioration in server performance. This is why, it is imperative that administrators track memory usage, detect if actual usage has reached the maximum memory configuration of the server, and configure suitable eviction policies to resolve the memory contention. To achieve this, administrators can use the Redis Memory test.

This test reports the memory usage of the Redis server and the maximum memory that the server is configured to use. Administrators are notified if the actual memory usage reaches the maximum memory configuration, thus prompting them to configure appropriate eviction policies. Additionally, the test sheds light on problem conditions such as memory fragmentation and memory swapping, so that administrators can fine-tune memory allocations based on the memory demands of the server operating system.

Target of the test :A Redis server

Agent deploying the test : An internal agent (recommended)

Outputs of the test : One set of results for the target Redis server

Configurable parameters for the test
Parameters	Description
Test period	How often should the test be executed
Host	The host for which the test is to be configured.
Port	The port at which the specified HOST listens.
Redis Password and Confirm Password	In some high security environments, a password may have been set for the Redis server, so as to protect it from unauthorized accesses/abuse. If such a password has been set for the monitored Redis server, then specify that password against REDIS PASSWORD. Then, confirm the password by retyping it against CONFIRM PASSWORD. If the Redis server is not password protected, then do not disturb the default setting of this parameter. To determine whether/not the target Redis server is password-protected, do the following: Login to the system hosting the Redis server. Open the redis.conf file in the <REDIS_INSTALL_DIR>. Look for the requirepass parameter in the file. If this parameter exists, and is not preceded by a # (hash) symbol, it means that password protection is enabled for the Redis server. In this case, the string that follows the requirepass parameter is the password of the Redis server. For instance, say that the requirepass specification reads as follows: requirepass red1spr0 According to this specification, the Redis server is protected using the password red1spr0. In this case therefore, you need to specify red1spr0 against REDIS PASSWORD. On the other hand, if the requirepass parameter is prefixed by the # (hash) symbol as shown below, it means password protection is disabled. # requirepass red1spr0 In this case, leave the REDIS PASSWORD parameter with its default setting.

Measurements made by the test
Measurement	Description	Measurement Unit	Interpretation
Maximum memory allocated to Redis	Indicates the value of the maxmemory configuration directive of the server.	MB	The maxmemory configuration directive is used in order to configure Redis to use a specified amount of memory for the data set. Setting maxmemory to zero results into no memory limits. This is the default behavior for 64 bit systems, while 32 bit systems use an implicit memory limit of 3GB.
Used memory	Indicates the amount of memory used by the server.	MB	If the value of this measure is equal to the value of the Maximum memory allocated to Redis measure, it indicates that the server has exhausted its memory limit. The exact behavior Redis follows when the maxmemory limit is reached is configured using the maxmemory-policy configuration directive. The following policies are available: noeviction: return errors when the memory limit was reached and the client is trying to execute commands that could result in more memory to be used (most write commands, but DEL and a few more exceptions). allkeys-lru: evict keys by trying to remove the less recently used (LRU) keys first, in order to make space for the new data added. volatile-lru: evict keys by trying to remove the less recently used (LRU) keys first, but only among keys that have an expire set, in order to make space for the new data added. allkeys-random: evict keys randomly in order to make space for the new data added. volatile-random: evict keys randomly in order to make space for the new data added, but only evict keys with an expire set. volatile-ttl: evict keys with an expire set, and try to evict keys with a shorter time to live (TTL) first, in order to make space for the new data added. The policies volatile-lru, volatile-random and volatile-ttl behave like noeviction if there are no keys to evict matching the prerequisites. Picking the right eviction policy is important depending on the access pattern of your application, however you can reconfigure the policy at runtime while the application is running, and monitor the number of cache misses and hits using the Redis INFO output in order to tune your setup. In general as a rule of thumb: Use the allkeys-lru policy when you expect a power-law distribution in the popularity of your requests, that is, you expect that a subset of elements will be accessed far more often than the rest. This is a good pick if you are unsure. Use the allkeys-random if you have a cyclic access where all the keys are scanned continuously, or when you expect the distribution to be uniform (all elements likely accessed with the same probability). Use the volatile-ttl if you want to be able to provide hints to Redis about what are good candidate for expiration by using different TTL values when you create your cache objects. The volatile-lru and volatile-random policies are mainly useful when you want to use a single instance for both caching and to have a set of persistent keys. However it is usually a better idea to run two Redis instances to solve such a problem. It is also worth noting that setting an expire to a key costs memory, so using a policy like allkeys-lru is more memory efficient since there is no need to set an expire for the key to be evicted under memory pressure.
Memory used by lua engine	Indicates the amount of memory used by the lua engine.	MB
Peak memory consumed by Redis	Indicates the high watermark of memory consumption by the Redis server.	MB
Memory allocated for redis as seen by operating system	Indicates the amount of memory that Redis allocated as seen by the operating system.	MB
Memory fragmentation ratio	Indicates the the ratio of memory used by the operating system compared to the amount of memory allocated by Redis.	Percent	A fragmentation ratio less than 1.0 means that Redis requires more memory than is available on the system and so it has resorted to using swap memory resources. A fragmentation ratio greater than 1.0 indicates that fragmentation is taking place and the Redis instance is consuming more physical memory than has been requested. A healthy Redis server Memory fragmentation ratio is slightly more than 1.0. A ratio greater than 1.5 indicates that excessive fragmentation is taking place. In such instances, you should restart Redis server to allow the operating system to recover the memory that has become unusable due to fragmentation.
Total system memory	Indicates the total amount of memory the Redis host has.	MB