What are the potential blocking points of AOF? The following article summarizes some potential blocking points of AOF in Redis. I hope it will be helpful to you!
What are the potential blocking points of AOF
1. When Redis uses the fork child process to rewrite the AOF file, there are potential Blocking risk
1), fork child process
Fork child process, the main thread will definitely be blocked at the moment of fork (note that fork will not be a one-time Copy all memory data to the child process), fork uses the Copy On Write mechanism provided by the operating system, in order to avoid the long-term blocking problem caused by copying a large amount of memory data at once to the child process. [Related recommendations: Redis video tutorial]
But the fork child process needs to copy the necessary data structures of the process, one of which is copying the memory page table (virtual memory and Physical memory mapping index table), this copy process will consume a lot of CPU resources. The entire process will be blocked before the copy is completed. The blocking time depends on the memory size of the entire instance. The larger the instance, the larger the memory page table. The longer the fork blocking time.
After the copy of the memory page table is completed, the child process and the parent process point to the same memory address space. That is to say, although the child process is generated at this time, it does not apply for the same memory size as the parent process.
When will the memory of the father and son processes be truly separated?
"Realistic copy", as the name suggests, actually copies the real data in the memory when writing occurs. During this process, the parent process may also be at risk of blocking, which is the scenario introduced below.
2), The parent process writes during AOF rewriting
The fork child process points to the same memory as the parent process address space, at this time the child process can perform AOF rewriting and write all the data in the memory to the AOF file.
But at this time, the parent process will still have traffic written. If the parent process operates an existing key, then at this time the parent process will actually copy the memory data corresponding to the key and apply for a new one. In this way, gradually, the memory data of the father and son processes begin to separate, and the father and son processes gradually have their own independent memory spaces. Because memory allocation is allocated in units of pages, the default is 4k. If the parent process is operating a bigkey at this time, it will take longer to reapply for a large block of memory, which may cause the risk of blocking.
In addition, if the operating system turns on the huge page memory mechanism (Huge Page, page size 2M), then the probability of blocking when the parent process applies for memory will be greatly increased, so in the Redis machine The Huge Page mechanism needs to be turned off. Every time Redis forks to generate RDB or AOF rewrite is completed, you can see in the Redis log how much memory space the parent process has reapplied for.
3) Why doesn’t AOF rewrite reuse AOF’s own logs?
AOF rewrite doesn’t reuse AOF’s own logs:
One reason is that writing the same file between parent and child processes will inevitably cause competition problems. Controlling competition means that it will affect the performance of the parent process.
The second is that if the AOF rewrite process fails, then the original AOF file is equivalent to being contaminated and cannot be restored and used. Therefore, Redis AOF rewrites a new file. If the rewriting fails, just delete the file directly. It will not affect the original AOF file. After the rewriting is completed, just replace the old file.
For more programming-related knowledge, please visit: Programming Video! !
The above is the detailed content of Let's talk about the potential blocking points of AOF in Redis (summary). For more information, please follow other related articles on the PHP Chinese website!

Redis是现在最热门的key-value数据库,Redis的最大特点是key-value存储所带来的简单和高性能;相较于MongoDB和Redis,晚一年发布的ES可能知名度要低一些,ES的特点是搜索,ES是围绕搜索设计的。

本篇文章给大家带来了关于redis的相关知识,其中主要介绍了关于redis的一些优势和特点,Redis 是一个开源的使用ANSI C语言编写、遵守 BSD 协议、支持网络、可基于内存、分布式存储数据库,下面一起来看一下,希望对大家有帮助。

本篇文章给大家带来了关于redis的相关知识,其中主要介绍了Redis Cluster集群收缩主从节点的相关问题,包括了Cluster集群收缩概念、将6390主节点从集群中收缩、验证数据迁移过程是否导致数据异常等,希望对大家有帮助。

本篇文章给大家带来了关于redis的相关知识,其中主要介绍了Redis实现排行榜及相同积分按时间排序,本文通过实例代码给大家介绍的非常详细,对大家的学习或工作具有一定的参考借鉴价值,希望对大家有帮助。

本篇文章给大家带来了关于redis的相关知识,其中主要介绍了关于原子操作中命令原子性的相关问题,包括了处理并发的方案、编程模型、多IO线程以及单命令的相关内容,下面一起看一下,希望对大家有帮助。

本篇文章给大家带来了关于redis的相关知识,其中主要介绍了bitmap问题,Redis 为我们提供了位图这一数据结构,位图数据结构其实并不是一个全新的玩意,我们可以简单的认为就是个数组,只是里面的内容只能为0或1而已,希望对大家有帮助。

本篇文章给大家带来了关于redis的相关知识,其中主要介绍了Redis实现排行榜及相同积分按时间排序,本文通过实例代码给大家介绍的非常详细,下面一起来看一下,希望对大家有帮助。

本篇文章给大家带来了关于redis的相关知识,其中主要介绍了关于实现秒杀的相关内容,包括了秒杀逻辑、存在的链接超时、超卖和库存遗留的问题,下面一起来看一下,希望对大家有帮助。


Hot AI Tools

Undresser.AI Undress
AI-powered app for creating realistic nude photos

AI Clothes Remover
Online AI tool for removing clothes from photos.

Undress AI Tool
Undress images for free

Clothoff.io
AI clothes remover

AI Hentai Generator
Generate AI Hentai for free.

Hot Article

Hot Tools

SublimeText3 Mac version
God-level code editing software (SublimeText3)

SublimeText3 Linux new version
SublimeText3 Linux latest version

SecLists
SecLists is the ultimate security tester's companion. It is a collection of various types of lists that are frequently used during security assessments, all in one place. SecLists helps make security testing more efficient and productive by conveniently providing all the lists a security tester might need. List types include usernames, passwords, URLs, fuzzing payloads, sensitive data patterns, web shells, and more. The tester can simply pull this repository onto a new test machine and he will have access to every type of list he needs.

WebStorm Mac version
Useful JavaScript development tools

SublimeText3 English version
Recommended: Win version, supports code prompts!
