This topic describes the specifications of DRAM-based cluster instances of Tair (Enterprise Edition). These specifications include the memory capacity, maximum number of connections, maximum bandwidth, and queries per second (QPS) reference value.
For this series of instance specifications, the
number of shards
is 2, the number of CPU cores is 12 (6 cores per shard), and the maximum number of new connections per second is 50,000.
For this series of instance specifications, the
number of shards
is 4, the number of CPU cores is 24 (6 cores per shard), and the maximum number of new connections per second is 50,000.
For this series of instance specifications, the
number of shards
is 8, the number of CPU cores is 48 (6 cores per shard), and the maximum number of new connections per second is 50,000.
For this series of instance specifications, the
number of shards
is 16, the number of CPU cores is 96 (6 cores per shard), and the maximum number of new connections per second is 50,000.
For this series of instance specifications, the
number of shards
is 32, the number of CPU cores is 192 (6 cores per shard), and the maximum number of new connections per second is 50,000.
For this series of instance specifications, the
number of shards
is 64, the number of CPU cores is 384 (6 cores per shard), and the maximum number of new connections per second is 50,000.
For this series of instance specifications, the
number of shards
is 128, the number of CPU cores is 768 (6 cores per shard), and the maximum number of new connections per second is 50,000.
For this series of instance specifications, the
number of shards
is 256, the number of CPU cores is 1,536 (6 cores per shard), and the maximum number of new connections per second is 50,000.
To ensure service stability, the system reserves a CPU core to process
background tasks.
In a cluster instance or a read/write splitting instance, the system reserves a CPU core for each shard or read replica to process background tasks.
Calculation rules for bandwidth values
Each bandwidth value in the preceding tables represents the maximum bandwidth for an instance of the corresponding instance type, which is the combined bandwidth of all shards or nodes in the instance. The maximum bandwidth for each shard is 96 Mbit/s.
If the default proxy endpoint is used by a cluster instance, the maximum bandwidth for the cluster instance is 2,048 Mbit/s. After the upper limit is reached, the bandwidth cannot be increased even if you add more shards to the cluster instance.
Note
To handle network traffic peaks, you can enable the direct connection mode. For more information, see Enable the direct connection mode. The direct connection mode is applicable only to cluster instances. In direct connection mode, the maximum bandwidth of the instance is equal to the maximum bandwidth of a single shard multiplied by the number of shards. For example, if a cluster instance contains 128 shards and each shard is allocated a memory of more than 1 GB, the maximum bandwidth of the instance is 12,288 Mbit/s.
The bandwidth value applies to the upstream and downstream bandwidths. For example, if the bandwidth of an instance is 10 Mbit/s, the upstream and downstream bandwidths of the instance are both 10 Mbit/s.
Note
If your instance may experience an unexpected or anticipated surge in traffic, you can adjust the bandwidth of the instance on demand. For more information, see Manually increase the bandwidth of an instance.
The bandwidth limits of Tair and Redis refer to the data transfer capacity of individual shards within their respective distributed systems. The limits are generally independent of the network connection types used by clients to connect to the shards.
Proxy mode: 500,000. If the upper limit of 500,000 connections is reached, subsequent connections cannot be established even if you add more shards or nodes.
Note
If your instance is created before March 1, 2020 and runs in proxy mode, the maximum number of connections to the instance is 200,000.
When you run a specific Pub/Sub, blocking, or transaction command on a cluster instance in proxy mode, the system establishes a dedicated backend connection for your client. In this case, the maximum number of connections to the instance is subject to the maximum number of connections to a single shard in direct connection mode. This is because the connections cannot be aggregated in this scenario.
Direct connection mode: The maximum number of connections to a single shard is 30,000. The maximum number of connections to an instance can be calculated by using the following formula: Number of shards × 30,000.
Maximum number of new connections per second
The maximum number of new connections per second refers to the number of connections that can be established per second.
Proxy mode: 50,000. For example, assume that the actual number of connections at the Nth second after the instance starts to run is 12,000. In this case, at the (N+1)th second, the maximum number of connections is 62,000. This value is calculated by using the following formula: 12,000 + 50,000.
Note
When you run a specific Pub/Sub, blocking, or transaction command on a cluster instance in proxy mode, the actual number of new connections to the instance per second is subject to the maximum number of connections to a single shard in direct connection mode.
Direct connection mode: 2,000. For example, if an instance has four data shards, the maximum number of new connections to the instance per second is 8,000.
FAQ
Why is the actual bandwidth of my instance different from the bandwidth described in this topic?
The bandwidths of specific instance types may be adjusted after the service is upgraded. If the actual bandwidth of your instance is different from that described in this topic, you can change the configurations of your instance by selecting the same instance type to update the bandwidth. The price of your instance remains unchanged after the configuration change. For more information, see Change the configurations of an instance.
Why am I unable to write data to a cluster instance when instance memory is not exhausted?
This is because the instance contains exhausted shards. Redis uses the hash algorithm to evenly write data to different shards. If the instance contains large keys, resources are unevenly distributed in the instance and the shards that house these large keys may even be exhausted. In this case, specific write requests to the instance may fail.
Elastic Compute Service (ECS)
Container Compute Service (ACS)
