eG Monitoring
 

Measures reported by RedisStatsTest

The RedisStatsTest presents to you a plethora of useful metrics on the performance of the Redis server, and quickly points you to the problem areas. With the help of these metrics, you can figure out:

  • Are there more keyspace misses than hits? If so, what could be causing them - expired keys? or evicted keys?

  • Are too many connections contending for the server's resources?

  • Were any connections rejected?

  • Is the network throughput of the server optimal?

  • Are more full synchronizations happening than partial ones?

  • Are partial synchronizations failing?

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

The measures made by this test are as follows:

Measurement Description Measurement Unit Interpretation
keyspace_hits_per_second Indicates the number of times the keyspace was looked up for keys every second. Number  
keyspace_hits Indicates the number of times the keyspace was able to successfully service key requests. Number Ideally, the value of this measure should be high.
keyspace_misses Indicates the number of times the keyspace failed to service key requests. Number Ideally, the value of this measure should be 0 or low

A higher value implies that the keyspace is consistently failing to service requests it receives, because the data being requested is not available in the keyspace. This usually means that one of the following happened:

  • The key expired

  • They key was renamed

  • The key was deleted

  • The key was evicted due to memory pressure

  • The entire database was flushed

  • The key was never actually inserted

  • The data was lost due to a crash, failover, etc.

  • The data is in a different DB than the one you currently selected.

A lower hit ratio results in larger latency as most of the requests are fetching data from the disk. It indicates that you need to increase the size of the keyspace to improve your application's performance.
expired_keys Indicates the total number of key expiration events. Number Normally Redis keys are created without an associated time to live. The key will simply live forever, unless it is removed by the user in an explicit way, for Normally Redis keys are created without an associated time to live. The key will simply live forever, unless it is removed by the user in an explicit way, for instance using the DEL command.

The EXPIRE family of commands is able to associate an expire to a given key, at the cost of some additional memory used by the key. When a key has an expire set, Redis will make sure to remove the key when the specified amount of time elapsed.

If the value of the keyspace_misses is abnormally high, then you may want to check if this measure is reporting a high value as well. If so, then you can conclude that the keyspace misses are being caused by a large number of expired keys.
evicted_keys Indicates the number of evicted keys. Number Typically, Redis automatically evicts keys if its maxmemory configuration setting is violated.

If the value of the keyspace_misses is abnormally high, then you may want to check if this measure is reporting a high value as well. If so, then you can conclude that the keyspace misses are being caused by a large number of evicted keys.
total_connections_received Indicates the total number of connections accepted by the server. Number An abnormally high value for this measure or a consistent increase in the value of this measure is a cause for concern.

Because Redis is single-threaded, one process serves requests from all clients. As the number of clients grows, the percentage of resource time given to each client decreases and each client spends an increasing amount of time waiting for their share of Redis server time. Monitoring the number of clients is important because there may be applications creating client connections that you did not expect or your application may not be efficiently closing unused connections.
rejected_connections Indicates the number of connections that were rejectedIndicates the number of connections that were rejected Number Redis server allows you to control the maximum number of client connections for your Redis server with the redis.conf directive “ maxclients ”. You can also set the maxclients limit from the rediscli by typing config set maxclients <value>. You should set maxclients to between 110% and 150% of your expected peak number of connections,depending on variation in your connections load. Connections that exceed your defined limit will be rejected and closed immediately.

Setting a maximum is important for limiting the number of unintended client connections. In addition, because an error message is returned for failed connection attempts, the maxclient limit helps warn you that a significant number of unexpected connections are occurring. Both are important for controlling the total number of connections and ultimately maintaining optimal Redis performance.
total_commands_processed Indicates the total number of commands processed by the server. Number This is a good measure of the workload of the server.
total_net_input_bytes Indicates the total number of bytes read from the network. MB Low values for these measures are indicative of low network throughput.
total_net_output_bytes Indicates the total number of bytes written to the network. MB Low values for these measures are indicative of low network throughput.
instantaneous_ops_per_sec Indicates the number of commands processed per second. Number Ideally, the value of this measure should be high, as it indicates that the server has high processing power.
instantaneous_input_kbps Indicates the network's read rate per second. Kbps  
instantaneous_output_kbps Indicates the network's write rate per second. Kbps  
sync_full Indicates the number of times slaves have fully synchronized with the master Number When a partial resynchronization is not possible, the replica will ask for a full resynchronization. This will involve a more complex process in which the master needs to create a snapshot of all its data, send it to the replica, and then continue sending the stream of commands as the dataset changes.
sync_partial_ok Indicates the number of times partial synchronizations have occurred between slaves and the master. Number When the link between the master and the replica breaks, for network issues or because a timeout is sensed in the master or the replica,the replica reconnects and attempts to proceed with a partial resynchronization: it means that it will try to just obtain the part of the stream of commands it missed during the disconnection.
sync_partial_err Indicates the number of times partial synchronizations have failed. Number Ideally, the value of this measure should be 0.
pubsub_channels Indicates the global number of pub/sub channels with client subscriptions. Number SUBSCRIBE, UNSUBSCRIBE and PUBLISH implement the Publish/Subscribe messaging paradigm where (citing Wikipedia) senders (publishers) are not programmed to send their messages to specific receivers (subscribers). Rather, published messages are characterized into channels, without knowledge of what (if any) subscribers there may be. Subscribers express interest in one or more channels, and only receive messages that are of interest, without knowledge of what (if any) publishers there are. This decoupling of publishers and subscribers can allow for greater scalability and a more dynamic network topology.
pubsub_patterns Indicates the global number of pub/sub patterns with client subscriptions Number The Redis Pub/Sub implementation supports pattern matching. Clients may subscribe to glob-style patterns in order to receive all the messages sent to channel names matching a given pattern.
latest_fork_usec Indicates the duration of the latest fork operation. Microseconds A low value is desired for this measure.
migrate_cached_sockets Indicates the number of sockets open for MIGRATE purposes. Number The MIGRATE command atomically transfers a key from a source Redis instance to a destination Redis instance. On success the key is deleted from the original instance and is guaranteed to exist in the target instance.

The command is atomic and blocks the two instances for the time required to transfer the key. At any given time the key will appear to exist in a given instance or in the other instance, unless a timeout error occurs.