Linux上是否存在Thundering Herd问题？

Question

许多linux/unix编程书籍和教程都讲述了"Thundering Herd Problem",它发生在select()调用中阻塞多个线程或分叉以等待侦听套接字的可读性时.当连接进入时,所有线程和分叉都被唤醒,但只有一个"胜利"并成功调用"accept()".与此同时,浪费了大量的cpu时间无缘无故地唤醒所有线程/分叉.

我注意到一个项目在linux内核中为这个问题提供了"修复",但这是一个非常古老的补丁.

我认为有两种变体; 一个是每个fork执行select()然后是accept(),另一个执行accept().

现代的unix/linux内核在这两种情况下仍然有Thundering Herd问题,还是只有"select()then accept()"版本？

Answer 1

这是一个非常古老的问题,而且大部分都不存在了.Linux内核(过去几年)在处理和路由数据包到网络堆栈的方式上进行了许多更改,并包括许多优化以确保低延迟和公平性(即最小化饥饿).

也就是说,select系统仅通过其API就存在许多可伸缩性问题.当您拥有大量文件描述符时,select调用的成本非常高.这主要是由于必须构建,检查和维护传递给系统调用和从系统调用传递的FD集.

现在,使用epoll进行异步IO的首选方法.API更简单,并且可以在各种类型的负载(许多连接,大量吞吐量等)上进行非常好的扩展.

Answer 2

多年来,大多数unix/linux内核序列化对accept(2)s的响应,换句话说,如果多个人在一个打开的文件描述中阻塞accept(2),则只唤醒一个线程.

OTOH,许多(如果不是全部)内核在你描述的select-accept模式中仍然存在雷鸣般的群体问题.

我编写了一个简单的脚本(https://gist.github.com/kazuho/10436253)来验证问题是否存在,并发现Linux 2.6.32和Darwin 12.5.0(OS X 10.8)存在问题. .5).

Answer 3

它就在那里，而且是真实的。请参阅我们在 uwsgi 中看到的这个问题：https ://github.com/unbit/uwsgi/issues/2611

如果我在 uwsgi 中禁用 --thunder-lock 选项，这意味着 uwsgi 将不会使用系统的正确 api/锁定机制。在这种情况下，在我的峰值负载期间，我可以看到大量的上下文切换和大量的时间浪费。我的应用程序的响应时间始终如一。（我正在谈论我的服务器上每分钟 1 个 Lac 请求）。