When a Tair or Redis instance experiences high CPU utilization or memory pressure, large keys and hot keys are often the root cause. Large keys consume excessive memory; hot keys concentrate traffic and can push an instance's CPU or network bandwidth to its limits, causing slowdowns or outages. The Top Key Statistics feature shows real-time and historical data about which keys are largest (by element count or memory) and which are most frequently accessed (by QPS or traffic), so you can locate and fix the root cause of performance issues quickly.
This feature tracks only keys that clients have actively read or written. It does not scan all keys in real time. Keys that have not been accessed recently may not appear in the results. After an instance restarts or a high availability (HA) failover occurs, the collected statistics are cleared and collection restarts from scratch. To analyze memory usage across all keys regardless of access history, use Offline Key Analysis.
How it works
Top Key Statistics collects four categories of keys:
| Category | Applicable versions | Threshold | Display |
|---|---|---|---|
| Large key (by number of elements) | Redis Open-Source Edition 5.0 and later; Tair (Enterprise Edition) | A key is counted as a large key when its element count (such as fields in a Hash or members in a Set) reaches or exceeds the threshold. Default: 2,000 elements. Adjust with the bigkey-threshold parameter. If bigkey-threshold is not listed in the parameter settings, update the minor version first. | Top 3 large keys per data type. Ties are broken by write time — the key written earlier appears first. If the instance shows only 3 large keys in total, update the minor version and retry. |
| Large key (by memory usage) | Cloud-native memory-optimized Tair (Enterprise Edition) instances, minor version 25.6.0.0 or later | A key is counted as a large key if its total memory usage exceeds the threshold (default: 500 MB, adjustable via bigkey-mem-threshold) or if a single element uses more than 50 MB. | Top 3 large keys. Ties are sorted in lexicographic order. |
| Hot key (by QPS) | Redis Open-Source Edition 5.0 and later; Tair (Enterprise Edition) | A key is counted as a hot key when its queries per second (QPS) exceeds the threshold. Default: 5,000 QPS. Adjust with the hotkey-threshold parameter. | Top 50 hot keys at any given time, with precise real-time QPS. Earlier minor versions (before Redis Open-Source Edition 7.0.18, 6.0.2.9, or 5.5.2.9; or before memory-optimized Tair 5.0.50 and 25.2.0.0) had a fixed threshold of 3,000 QPS that could not be changed, showed only an approximate QPS range, and limited Redis Open-Source Edition statistics to 20 hot keys. Upgrade to the latest minor version to get full hot key visibility. |
| Hot key (by traffic) | Cloud-native memory-optimized Tair (Enterprise Edition) instances, minor version 25.2.0.0 or later | A key is counted as a hot key when its access traffic exceeds 1 MB/s. This category is disabled by default. Enable it by setting the #no_loose_high-cost-key-enabled parameter to yes. Adjust the traffic threshold (in B/s) with #no_loose_high-cost-key-traffic-bytes-threshold. To track keys that individually have low traffic but belong to a high-traffic hashtag or prefix group, set #no_loose_high-cost-key-parse-hashtag — requires minor version 25.9.1.0 or later. | Top 50 hot keys at any given time, with precise inbound and outbound traffic and access frequency. Statistics can include keys that do not exist in the database; these appear with the data type not-exist-key. |
View top key statistics
Log on to the console and go to the Instances page. In the top navigation bar, select the region where your instance resides. Find the instance and click its ID.
In the left navigation pane, choose CloudDBA > Top Key Statistics.
Select Real-time or Historical to choose the data you want to view. Figure 1. Key analysis
For instances using a cluster architecture or a read/write splitting architecture, select a node from the Current Node drop-down list to view per-node data.
Historical data covers the last four days. A single query cannot span more than three hours.
API reference
Use DAS API operations to retrieve top key data programmatically.
| API operation | Description |
|---|---|
| DescribeHotBigKeys | Gets real-time information about hot keys and large keys currently in memory. |
| DescribeTopHotKeys | Gets information about the top 20 hot keys over a time period. |
| DescribeTopBigKeys | Gets information about the top 20 large keys over a time period. |
| DescribeHotKeys | Gets hot key information for a Redis instance. |
FAQ
Why do String-type keys appear under Large key (by number of elements)?
In Redis Open-Source Edition and some earlier versions of Tair, String keys are included if their length exceeds the bigkey-threshold value (default: 2,000).
Why does a key with fewer than 10 elements appear as a large key?
The most likely cause is that the key name itself is large. Run memory usage key_name to check its actual memory footprint. If the result is unexpectedly high, consider renaming or restructuring the key.
A less common cause is an outdated minor version. Instances with a minor version earlier than 5.2.7 have a default bigkey-threshold of 0, which causes keys with small memory usage to appear as large keys. Upgrade the minor version to resolve this.
What's next
If your use case involves leaderboards with more than 100,000 elements using the Zset data structure, use Tair's exZset data structure. With the TairJedis client, you can implement leaderboards with a distributed architecture under a single key — Tair automatically distributes data and computation across sub-keys, preventing oversized keys and hot keys from forming.
To troubleshoot high CPU utilization, see Troubleshoot high CPU utilization of an instance.
To troubleshoot high memory usage, see Troubleshoot high memory usage of an instance.