Modifying Configuration Parameters
You can modify the configuration parameters of your DCS instance to optimize DCS performance based on your requirements.
For example, if you do not need data persistence, set appendonly to no.
After the instance configuration parameters are modified, the modification takes effect immediately without the need to manually restart the instance. For a cluster instance, the modification takes effect on all shards.
Procedure
- Log in to the DCS console.
- Click in the upper left corner of the management console and select a region and a project.
- In the navigation pane, choose Cache Manager.
- On the Cache Manager page, click the name of the DCS instance you want to configure.
- On the instance details page, click the Parameters tab.
- On the Parameters tab page, click Modify.
- Modify parameters based on your requirements.
Table 1 describes the parameters. In most cases, retain the default values.
Table 1 DCS Redis instance configuration parameters Parameter
Description
Value Range
Default Value
timeout
The maximum amount of time (in seconds) a connection between a client and the DCS instance can be allowed to remain idle before the connection is terminated. A setting of 0 means that this function is disabled.
0–7200 seconds
0
appendfsync
Controls how often fsync() transfers cached data to the disk. Note that some OSs will perform a complete data transfer but some others only make a "best-effort" attempt.
There are three settings:
no: fsync() is never called. The OS will flush data when it is ready. This mode offers the highest performance.
always: fsync() is called after every write to the AOF. This mode is very slow, but also very safe.
everysec: fsync() is called once per second. This mode provides a compromise between safety and performance.
- no
- always
- everysec
everysec
appendonly
Indicates whether to log each modification of the instance. By default, data is written to disks asynchronously in Redis. If this function is disabled, recently-generated data might be lost in the event of a power failure. Options:
yes: enabled
no: disabled
- yes
- no
yes
client-output-buffer-limit-slave-soft-seconds
Number of seconds that the output buffer remains above client-output-buffer-slave-soft-limit before the client is disconnected.
0–60
60
client-output-buffer-slave-hard-limit
Hard limit (in bytes) on the output buffer of replica clients. Once the output buffer exceeds the hard limit, the client is immediately disconnected.
0–17,179,869,184
1,717,986,918
client-output-buffer-slave-soft-limit
Soft limit (in bytes) on the output buffer of replica clients. Once the output buffer exceeds the soft limit and continuously remains above the limit for the time specified by the client-output-buffer-limit-slave-soft-seconds parameter, the client is disconnected.
0–17,179,869,184
1,717,986,918
maxmemory-policy
The policy applied when the maxmemory limit is reached.
For more information about this parameter, see https://redis.io/topics/lru-cache.
volatile-lru
allkeys-lru
volatile-random
allkeys-random
volatile-ttl
noeviction
noeviction
lua-time-limit
Maximum time allowed for executing a Lua script (in milliseconds).
5000
100–5000
master-read-only
Sets the instance to be read-only. All write operations will fail.
- yes
- no
no
maxclients
The maximum number of clients allowed to be concurrently connected to a DCS instance.
1000–10,000
10,000
proto-max-bulk-len
Maximum size of a single element request (in bytes).
1,048,576–536,870,912
536,870,912
repl-backlog-size
The replication backlog size (bytes). The backlog is a buffer that accumulates replica data when replicas are disconnected from the master. When a replica reconnects, a partial synchronization is performed to synchronize the data that was missed while replicas were disconnected.
16,384–1,073,741,824
1,048,576
repl-backlog-ttl
The amount of time, in seconds, before the backlog buffer is released, starting from the last a replica was disconnected. The value 0 indicates that the backlog is never released.
0–604,800
3,600
repl-timeout
Replication timeout (in seconds).
30–3,600
60
hash-max-ziplist-entries
The maximum number of hashes that can be encoded using ziplist, a data structure optimized to reduce memory use.
1–10,000
512
hash-max-ziplist-value
The largest value allowed for a hash encoded using ziplist, a special data structure optimized for memory use.
1–10,000
64
set-max-intset-entries
If a set is composed entirely of strings that are integers in radix 10 within the range of 64 bit signed integers, the set is encoded using intset, a data structure optimized for memory use.
1–10,000
512
zset-max-ziplist-entries
The maximum number of sorted sets that can be encoded using ziplist, a data structure optimized to reduce memory use.
1–10,000
128
zset-max-ziplist-value
The largest value allowed for a sorted set encoded using ziplist, a special data structure optimized for memory use.
1–10,000
64
latency-monitor-threshold
The minimum amount of latency that will be logged as latency spikes
If this parameter is set to 0, latency monitoring is disabled. If this parameter is set to a value greater than 0, all events blocking the server for a time greater than the configured value will be logged.
By running the LATENCY command, you can perform operations related to latency monitoring, such as obtaining statistical data, and configuring and enabling latency monitoring. For more information about the latency-monitor-threshold, visit https://redis.io/topics/latency-monitor.
0–86,400,000 ms
0
notify-keyspace-events
Controls which keyspace events notifications are enabled for. If this parameter is configured, the Redis Pub/Sub feature will allow clients to receive an event notification when a Redis data set is modified.
A string of different values can be used to enable notifications for multiple event types: Possible values include:
K: Keyspace events, published with the __keyspace@__ prefix
E: Keyevent events, published with __keyevent@__ prefix
g: Generic commands (non-type specific) such as DEL, EXPIRE, and RENAME
$: String commands
l: List commands
s: Set commands
h: Hash commands
z: Sorted set commands
x: Expired events (events generated every time a key expires)
e: Evicted events (events generated when a key is evicted from maxmemory)
For more information, see the following note.
Ex
slowlog-log-slower-than
The maximum amount of time allowed, in microseconds, for command execution. If this threshold is exceeded, Redis Slow Log will record the command.
0–1,000,000
10,000
slowlog-max-len
The maximum allowed length of the Redis Slow Log logs. Slow Log consumes memory, but you can reclaim this memory by running the SLOWLOG RESET command.
0–1000
128
- For more information about the parameters described in Table 1, visit https://redis.io/topics/memory-optimization.
- The latency-monitor-threshold parameter is usually used for fault location. After locating faults based on the latency information collected, change the value of latency-monitor-threshold to 0 to avoid unnecessary latency.
- More about the notify-keyspace-events parameter:
- The parameter setting must contain at least a K or E.
- A is an alias for "g$lshzxe" and cannot be used together with any of the characters in "g$lshzxe".
- For example, the value Kl means that Redis will notify Pub/Sub clients about keyspace events and list commands. The value AKE means Redis will notify Pub/Sub clients about all events.
- After you have finished setting the parameters, click Save.
- Click Yes to confirm the modification.
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot