Shulou(Shulou.com)06/01 Report--

What are the common problems with redis performance? This problem may be often seen in our daily study or work. I hope you can gain a lot from this question. The following is the reference content that the editor brings to you, let's take a look at it!

Master writes memory snapshots, and the save command schedules the rdbSave function, which will block the work of the main thread. When the snapshot is relatively large, it will have a great impact on performance and will intermittently suspend the service, so it is best not to write memory snapshots for Master.

Master AOF persistence, if you do not rewrite AOF files, this persistence method will have the least impact on performance, but AOF files will continue to grow, and excessive AOF files will affect the recovery speed of Master restart.

When Master calls BGREWRITEAOF to rewrite the AOF file, AOF will take up a lot of CPU and memory resources when rewriting, resulting in excessive service load and temporary service suspension.

The following is the situation of one of my actual projects, which goes something like this:

There is no Sharding mechanism for one Master,4 Slave, only read and write separation, Master is responsible for write operation and AOF log backup, and AOF file is about 5G Slave responsible for read operation. When Master calls BGREWRITEAOF, the load of Master and Slave will suddenly increase sharply, Master write requests basically do not respond, lasting about 5 minutes, more than half of Slave read requests can not respond in time, the above situation should not and should not have happened. Because the Master machine used to be Slave, there was a shell scheduled task on it that called BGREWRITEAOF at 10:00 every morning to rewrite the AOF file. Later, because the Master machine down, the Slave that was backed up was cut into Master, but the scheduled task forgot to delete, which led to the tragic situation above. It took several days to find the reason.

Setting the configuration of no-appendfsync-on-rewrite to yes can alleviate this problem. Setting it to yes means that new writes are not fsync during rewrite, and are temporarily stored in memory, and then written after the rewrite is completed. It is best not to enable the AOF backup function of Master.

Due to the performance problem of Redis master-slave replication, the first time that Slave synchronizes to Master is that Slave sends synchronization request to Master, Master first dump out rdb files, then transfers all rdb files to slave, and then Master forwards the cached commands to Slave, and the first synchronization is completed. The second and subsequent synchronization implementation is that Master sends snapshots of variables directly to each Slave in real time. No matter what causes Slave and Master to disconnect and reconnect, the above process will be repeated. The master-slave replication of Redis is based on the persistence of memory snapshots. As long as there is Slave, there must be memory snapshots. Although Redis claims that master-slave replication is non-blocking, due to the limitation of disk io, if the Master snapshot file is large, then dump will take a long time. In this process, Master may not be able to respond to the request, that is, the service will be interrupted. For critical services, this consequence is also terrible.

The root cause of the above 1.2.3.4 problems can not be separated from the bottleneck of the system io, that is, the read and write speed of the hard disk is not fast enough, and the main process fsync () / write () operation is blocked.

The problem of single point of failure, because the master-slave replication of Redis is not mature enough at present, there is an obvious problem of single point of failure, which can only be solved by ourselves, such as active replication, Proxy to replace Slave to Master and so on. This is also one of the priority tasks of Redis authors.

Thank you for reading! After reading the above, do you have a general understanding of the common problems with redis performance? I hope the content of the article will be helpful to all of you. If you want to know more about the relevant articles, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.