探索惊群 ④ - nginx - accept_mutex

[wenfh2020]

https://wenfh2020.com/2021/10/10/nginx-thundering-herd-accept-mutex/

前面已经说过，解决惊群问题的关键在于，多个子进程获取共享资源，不抢！另外还有一个资源分配不均的问题。看看 nignx 的 accept_mutex 特性是如何解决这两个问题的。由主进程创建的 listen socket，是被 fork 出来的子进程共享的，但是为了避免多个子进程同时争抢共享资源，nginx 采用一...

[cs-moushuai]

可是 accept_disabled > 0 时，该进程并没有 del listenfd 啊，那另一个进程抢到锁了监听了 listenfd，但是由于该进程还未 del listenfd，那是不是就有两个进程监听 listenfd，会有惊群吧

[wenfh2020]

@cs-moushuai 可是 accept_disabled > 0 时，该进程并没有 del listenfd 啊，那另一个进程抢到锁了监听了 listenfd，但是由于该进程还未 del listenfd，那是不是就有两个进程监听 listenfd，会有惊群吧

你好，这是个好问题！我发现其他开发者也提出了类似的问题，nginx 开发者作了回复， 详细请参考：​multiple users can still do "accept" when "accept_mutex" is "on", in a specific scenario。

大体意思：accept mutex 确实是为了解决惊群问题而设计的，如果进程出现 accept_disabled > 0 高负载情况，应该尽量减少它再获得锁的可能，提高其它进程获得锁的概率，但是不应该剥夺它继续获取新链接资源的权利（并没有 del listenfd）。

而 accept_disabled > 0 也是一种不正常的现象，用户也应该排查原因。

---

我原文也并没有考虑到 accept_disabled > 0 时 listenfd 并没删除的场景。

我自己对惊群的理解：

并不是说有多个进程监听 listenfd 就是惊群，而是有资源到来，系统是否 无差别 地唤醒所有进程（或多个进程）去获取资源，如果高负载场景，链接资源应该非常多，多个进程同时监听 listenfd 并无不妥。

[cs-moushuai]

@wenfh2020

@cs-moushuai 可是 accept_disabled > 0 时，该进程并没有 del listenfd 啊，那另一个进程抢到锁了监听了 listenfd，但是由于该进程还未 del listenfd，那是不是就有两个进程监听 listenfd，会有惊群吧

你好，这是个好问题！我发现其他开发者也提出了类似的问题，nginx 开发者作了回复， 详细请参考：​multiple users can still do "accept" when "accept_mutex" is "on", in a specific scenario。

大体意思：accept mutex 确实是为了解决惊群问题而设计的，如果进程出现 accept_disabled > 0 高负载情况，应该尽量减少它再获得锁的可能，提高其它进程获得锁的概率，但是不应该剥夺它继续获取新链接资源的权利（并没有 del listenfd）。

而 accept_disabled > 0 也是一种不正常的现象，用户也应该排查原因。

---

我原文也并没有考虑到 accept_disabled > 0 时 listenfd 并没删除的场景。

我自己对惊群的理解：

并不是说有多个进程监听 listenfd 就是惊群，而是有资源到来，系统是否 无差别 地唤醒所有进程（或多个进程）去获取资源，如果高负载场景，链接资源应该非常多，多个进程同时监听 listenfd 并无不妥。

感谢你的回复，高负载时不 del listenfd，而让多个线程 accept 能够缓解高负载时的压力，确实是很好的解决方案