“惊群”问题

分手后的思念是犯贱 2022-08-24 05:29 166阅读 0赞

读《UNIX网络编程》第二版的第一卷时，发现作者在第27章“客户-服务器程序其它设计方法”中的27.6节“TCP预先派生子进程服务器程序，accept无上锁保护”中提到了一种由子进程去竞争客户端连接的设计方法，用伪码描述如下:  
  
服务器主进程:

<table style="BORDER-COLLAPSE: collapse"> 
 <tbody> 
 <tr> 
 <td> <code>listen_fd = socket(...); bind(listen_fd, ...); listen(listen_fd, ...); pre_fork_children(...); close(listen_fd); wait_children_die(...); </code></td> 
 </tr> 
 </tbody> 
</table>

服务器服务子进程:

初识上述代码，真有眼前一亮的感觉，也正如作者所说，以上代码确实很少见（反正我读此书之前是确实没见过）。作者真是构思精巧，巧妙地绕过了常见的预先创建子进程的多进程服务器当主服务进程接收到新的连接必须想办法将这个连接传递给服务子进程的“陷阱”，上述代码通过共享的倾听套接字，由子进程主动地去向内核“索要”连接套接字，从而避免了用UNIX域套接字传递文件描述符的“淫技”。  
  
不过，当接着往下读的时候，作者谈到了“惊群”（Thundering herd)问题。所谓的“惊群”就是，当很多进程都阻塞在accept系统调用的时候，即使只有一个新的连接达到，内核也会唤醒所有阻塞在accept上的进程，这将给系统带来非常大的“震颤”，降低系统性能。  
  
除了这个问题，accept还必须是原子操作。为此，作者在接下来的27.7节讲述了加了互斥锁的版本：

<table style="BORDER-COLLAPSE: collapse"> 
 <tbody> 
 <tr> 
 <td> <code>while (1) { &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;lock(...); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;conn_fd = accept(listen_fd, ...); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;unlock(...); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;do_service(conn_fd, ...); } </code></td> 
 </tr> 
 </tbody> 
</table>

原子操作的问题算是解决了，那么“惊群”呢？文中只是提到在Solaris系统上当子进程数由75变成90后，CPU时间显著增加，并且作者认为这是因为进程过多，导致内存互换。对“惊群”问题回答地十分含糊。通过比较书中图27.2的第4列和第7列的内容，我们可以肯定“真凶”绝对不是“内存对换”。  
  
“元凶”到底是谁？  
  
仔细分析一下，加锁真的有助于“惊群”问题么？不错，确实在同一时间只有一个子进程在调用accept，其它子进程都阻塞在了lock语句，但是，当accept返回并unlock之后呢？unlock肯定是要唤醒阻塞在这个锁上的进程的，不过谁都没有规定是唤醒一个还是唤醒多个。所以，潜在的“惊群”问题还是存在，只不过换了个地方，换了个形式。而造成Solaris性能骤降的“罪魁祸首”很有可能就是“惊群”问题。  
  
崩溃了！这么说所有的锁都有可能产生惊群问题了？  
  
似乎真的是这样，所以 **减少锁的使用**很重要。特别是在竞争比较激烈的地方。  
  
作者在27.9节所实现的“传递文件描述符”版本的服务器就有效地克服了“惊群”问题，在现实的服务器实现中，最常用的也是此节所提到的基于“分配”形式。  
  
**把“竞争”换成“分配”**是避免“惊群”问题的有效方法，但是 **也不要忽视“分配”的“均衡”问题**，不然后果可能更加严重哦！