Redis persistence has always been a common factor affecting Redis performance. How can you monitor persistence and optimize it? Let’s take a look.


Monitoring and optimization of fork

Regardless of which persistence is used, RDB persistence or AOF overwriting, the main process forks out a child process that generates the RDB file or overwrites the AOF. Fork is a heavy operation for the operating system. In the fork phase, Redis blocks for a while. The blocking time is proportional to the amount of memory occupied by redis data, and the fork time is 20 milliseconds for every 1G memory.

If you want to know the blocking time for the fork phase, use the info STATS command to view the value of the latest_fork_usec option in microseconds. Remember microseconds, not milliseconds.

# redis-cli info stats | grep latest
latest_fork_usec:323Copy the code

Optimization of fork:

  • Controls how much memory redis occupies. If the memory usage is too large, you can split the application and deploy it on multiple servers to share the memory usage of Redis.
  • Reduce the frequency of fork operations.

Memory monitoring

RDB persistent logs are as follows:

... 21692:C 15 May 2020 14:17:06.935 * DB saved on disk 21692:C 15 May 2020 14:17:06.936 * RDB: 2 MB of memory used by copy-on-write......Copy the code

You can see that the RDB persistence process consumes 2M memory.

AOF persistence logs are as follows:

... 15786:C 23 May 2020 07:39:59.145 * AOF rewrite: 2MB of memory used by copy-on-write 10679:M 23 May 2020 07:39:59.201 * Background AOF rewrite terminated with success 10679:M 23 May 2020 07:39:59.201 * Residual parent diff successfully flushed to the rewritten AOF (0.02 MB) 10679:M 23 May 2020 07:39:59.201 * Background AOF rewrite finished successfullyCopy the code

As you can see, the memory footprint of aOF rewrite is 2MB+0.02MB=2.02MB

If you want to monitor the memory usage during persistence, you can write shell scripts to collect the relevant information in redis logs.

Hard Disk Monitoring

The Redis persistence process puts pressure on the hard disk because the data in memory is saved to the hard disk after persistence.

For example, if the I/O pressure of a disk exceeds the threshold, compare the persistence time based on redis logs to check whether the pressure is caused by redis persistence.

Two points are proposed in the optimization method:

  • Mechanical hard drives can’t compete with solid state drives when it comes to performance.
  • If several Redis instances are configured on a single machine, they can be written to different disks to reduce disk writing pressure.

Single-node multi-instance deployment

Because Redis is a single-threaded architecture, it is a waste of multi-core cpus if only one instance of Redis is deployed on a server. Therefore, it is common to deploy multiple redis applications on one server, such as enabling three redis services with port numbers 6379,6380,6381 respectively. 6379 for caching, 6380 for message queuing, 6381 for tagging and recommendation systems.

This does make good use of the CPU, but it can be problematic. If multiple instances are persisting at the same time, the strain on CPU, memory, and movies can be severe. It is good practice to isolate them so that only one instance is persisted at a time.

The pseudo-code for this effect is as follows:

while (true)
{
 $redisObj6379638 0 = [...] ; foreach ($redisObj as $obj) {// Whether this instance constitutes a rewriting requirementif (rewriteConf($ojb) {// This instance is persisted}}}Copy the code

Foreach is used to iterate over each redis instance and determine whether the instance meets the requirements for rewriting. This allows multiple Redis instances to be persisted and isolated.

To learn more, please visit:

Tencent T3-T4 standard boutique PHP architect tutorial directory directory, as long as you finish the guarantee salary rise a step (continue to update)


I hope the above content can help you. Many PHPer will encounter some problems and bottlenecks when they are advanced, and they have no sense of direction when writing too many business codes. I have sorted out some information, including but not limited to: Distributed architecture, high scalability, high performance, high concurrency, server performance tuning, TP6, Laravel, YII2, Redis, Swoole, Swoft, Kafka, Mysql optimization, shell scripting, Docker, microservices, Nginx, etc.