2、惊群现象

参考文献有

1:https://blog.csdn.net/russell_tao/article/details/7204260

2:https://www.jianshu.com/p/8f362e943e56

什么是“惊群”?

多线程/多进程(linux下线程进程也没多大区别)等待同一个socket事件,当这个事件发生时,这些线程/进程被同时唤醒,就是惊群。可以想见,效率很低下,许多进程被内核重新调度唤醒,同时去响应这一个事件,当然只有一个进程能处理事件成功,其他的进程在处理该事件失败后重新休眠(也有其他选择)。这种性能浪费现象就是惊群。
-------------------------------------

举一个很简单的例子,当你往一群鸽子中间扔一块食物,虽然最终只有一个鸽子抢到食物,但所有鸽子都会被惊动来争夺,没有抢到食物的鸽子只好回去继续睡觉, 等待下一块食物到来。这样,每扔一块食物,都会惊动所有的鸽子,即为惊群。

------------------------------------

造成的后果:

1)系统对用户进程/线程频繁的做无效的调度、上下文切换,系统系能大打折扣。

2)为了确保只有一个线程得到资源,用户必须对资源操作进行加锁保护,进一步加大了系统开销。

------------------------------------

对于惊群效应的场景描述,最常见的就是对于socket操作符的accept操作的描述。当多个用户进程/线程同时监听同一个端口时,由于实际上一个请求过来,只有一个进程/线程accept成功,所以就会产生惊群效应。

-----------------------------------------

linux解决方式:

线程池通知改变方式,有空闲线程则通知某一个;没空闲则广播(谁先完给谁,如果同时完成,那么又惊群了)。

----------------------------------------

nginx是怎么处理惊群

同一时刻只允许一个nginx worker在自己的epoll中处理监听句柄。它的负载均衡也很简单,当达到最大connection的7/8时,本worker不会去试图拿accept锁,也不会去处理新连接,这样其他nginx worker进程就更有机会去处理监听句柄,建立新连接了。而且,由于timeout的设定,使得没有拿到锁的worker进程,去拿锁的频繁更高。(没懂)

原文地址:https://www.cnblogs.com/westlife-11358/p/10469486.html

时间: 2024-09-30 19:05:30

2、惊群现象的相关文章

Redis 利用锁机制来防止缓存过期产生的惊群现象-转载自 http://my.oschina.net/u/1156660/blog/360552

首先,所谓的缓存过期引起的“惊群”现象是指,在大并发情况下,我们通常会用缓存来给数据库分压,但是会有这么一种情况发生,那就是在一定时间 内生成大量的缓存,然后当缓存到期之后又有大量的缓存失效,导致后端数据库的压力突然增大,这种现象就可以称为“缓存过期产生的惊群现象”! 以下代码的思路,就是利用“锁机制”来防止惊群现象.先看代码: class KomaRedis{ private $redis; //redis对象 private static $_instance = null; private

Nginx如何解决“惊群”现象

首先解释下什么是"惊群"现象:如果多个工作进程同时拥有某个监听套接口,那么一旦该套接口出现某客户端请求,此时就将引发所有拥有该套接口的工作进程去争抢这个请求,能争抢到的肯定只有某一个工作进程,而其他工作进程注定要无功而返,这种现象即为"惊群". Nginx解决这种"惊群"现象使用的是负载均衡的策略,接下来先结合Nginx的源码详细介绍下Nginx的这种负载均衡策略. 首先是Nginx如何开启负载均衡策略:当然运行的Nginx要是多进程模型,并且工

pthread_cond_signal惊群现象

1.如下代码所示: #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <pthread.h> pthread_mutex_t count_lock; pthread_cond_t count_ready; int count; void *decrement_count(void *arg) { while(1) { pthread_mutex_lock(&coun

Nginx中的惊群现象解决方法

*什么是惊群现象?Nginx中用了什么方法来避免这种问题的发生?本篇就解决这两个问题...→_→* 惊群现象的定义与危害 在Nginx中,每一个worker进程都是由master进程fork出来的.master进程创建socket后进行listen.bind操作,fork出来的worker继承了socket,调用accpet开始监听等待网络连接 如果这时有多个worker进程都在等待事件的发生.当事件发生时,这些worker进程被同时唤醒,但最终只有一个worker进程可以处理事件成功,其他的w

Accept 惊群现象测试perl脚本

$uname -a Linux debian-11-34 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt9-3~deb8u1 (2015-04-24) x86_64 GNU/Linux 经过测试Debina 8.0 已经解决了Aceept thundering herd https://gist.github.com/kazuho/10436253 # 1) run this script with either "accept" or "se

linux 惊群问题

1. 结论 对于惊群的资料,网上特别多,良莠不齐,也不全面.看的时候,有的资料说,惊群已经解决了,有的资料说,惊群还没解决.. 哪个才是对的?!  一怒之下,在研究各种公开资料的基础上,特意查对了linux源码,总结了此文.希望对有需要的人略有帮助,希望各位大神轻拍,如有错漏,不吝指教,感激不尽.([email protected]) 先说结论吧: 1. Linux多进程accept系统调用的惊群问题(注意,这里没有使用select.epoll等事件机制),在linux 2.6版本之前的版本存在

Linux网络编程“惊群”问题总结

1.前言 我从事Linux系统下网络开发将近4年了,经常还是遇到一些问题,只是知其然而不知其所以然,有时候和其他人交流,搞得非常尴尬.如今计算机都是多核了,网络编程框架也逐步丰富多了,我所知道的有多进程.多线程.异步事件驱动常用的三种模型.最经典的模型就是Nginx中所用的Master-Worker多进程异步驱动模型.今天和大家一起讨论一下网络开发中遇到的“惊群”现象.之前只是听说过这个现象,网上查资料也了解了基本概念,在实际的工作中还真没有遇到过.今天周末,结合自己的理解和网上的资料,彻底将“

accept与epoll惊群 转载

今天打开 OneNote,发现里面躺着一篇很久以前写的笔记,现在将它贴出来. 1. 什么叫惊群现象 首先,我们看看维基百科对惊群的定义: The thundering herd problem occurs when a large number of processes waiting for an event are awoken when that event occurs, but only one process is able to proceed at a time. After

Nginx源码分析 - 主流程篇 - 多进程的惊群和进程负载均衡处理

Linux2.6版本之前还存在对于socket的accept的惊群现象.之后的版本已经解决掉了这个问题. 惊群是指多个进程/线程在等待同一资源时,每当资源可用,所有的进程/线程都来竞争资源的现象. Nginx采用的是多进程的模式.假设Linux系统是2.6版本以前,当有一个客户端要连到Nginx服务器上,Nginx的N个进程都会去监听socket的accept的,如果全部的N个进程都对这个客户端的socket连接进行了监听,就会造成资源的竞争甚至数据的错乱.我们要保证的是,一个链接在Nginx的