Linux内核的软中断("softirq")机制有些奇怪,在早期的Linux和处理机制下比较晦涩,且仅有极少的内核开发人员会直接接触软中断。然而它是内核的大多数重要处理的核心。在某些场景下,软中断会以一种不合时宜的方式出现。特别是内核的实时抢占补丁集经常会与软中断产生冲突,该补丁集的最新版本提供了一种解决产生软中断问题的方法,值得一看。
设备的中断会打断内核进程中的正常调度和运行,系统对更高吞吐率的追求势必要求中断服务程序尽量短小精悍。但是,这个良好的愿望往往与现实并不吻合。在大多数真实的系统中,当中断到来时,要完成的工作往往并不会是短小的,它可能要进行较大量的耗时处理。 下图描述了Linux内核的中断处理机制。为了在中断执行时间尽量短和中断处理需完成的工作尽量大之间找到一个平衡点,Linux将中断处理程序分解为两个半部:顶半部和底半部。
(2)如何解决中断处理程序执行过长和中断丢失的问题: Linux 将中断处理过程分成了两个阶段,也就是上半部和下半部。 上半部用来快速处理中断,它在中断禁止模式下运行,主要处理跟硬件紧密相关的或时间敏感的工作。也就是我们常说的硬中断,特点是快速执行。 下半部用来延迟处理上半部未完成的工作,通常以内核线程的方式运行。也就是我们常说的软中断,特点是延迟执行。
处理外部事件是 CPU 必须要做的事,因为 CPU 和外设的不平等性导致外设的事件被 CPU 当作是外部事件,其实它们是平等的,只不过冯氏机器不这么认为罢了,既然要处理外部事件,那么就需要一定的方法,方法不止一种,大致有中断和轮询以及一种 混杂又复杂的方式,也就是DMA方式。中断是 CPU 被动处理的一种方式,也就是说 CPU 不知道何时中断,只要有了中断就会通知 CPU,而 CPU 此时必须停 下一切来处理,而轮询是 CPU 主动查询并处理的过程,CPU 隔一会查询一下外设看有没有事情可做。
| 导语 本文主要是讲Linux的调度系统, 由于全部内容太多,分三部分来讲,调度可以说是操作系统的灵魂,为了让CPU资源利用最大化,Linux设计了一套非常精细的调度系统,对大多数场景都进行了很多优化,系统扩展性强,我们可以根据业务模型和业务场景的特点,有针对性的去进行性能优化,在保证客户网络带宽前提下,隔离客户互相之间的干扰影响,提高CPU利用率,降低单位运算成本,提高市场竞争力。欢迎大家相互交流学习!
Linux内核对网络包的接收过程大致可以分为接收到RingBuffer、硬中断处理、ksoftirqd软中断处理几个过程。其中在ksoftirqd软中断处理中,把数据包从RingBuffer中摘下来,送到协议栈的处理,再之后送到用户进程socket的接收队列中。
前面的几篇文章里讨论过了进程上下文切换和系统调用对系统性能的影响,我们今天再来看另外一个CPU吃货,那就是软中断。
实时分为硬实时和软实时,硬实时要求绝对保证响应时间不超过期限,如果超过期限,会造成灾难性的后果,例如汽车在发生碰撞事故时必须快速展开安全气囊;软实时只需尽力使响应时间不超过期限,如果偶尔超过期限,不会造成灾难性的后果.
中断其实就是由硬件或软件所发送的一种称为IRQ(中断请求)的信号。中断允许让设备,如键盘,串口卡,并口等设备表明它们需要CPU。
从本质上来讲,中断是一种电信号,当设备有某种事件发生时,它就会产生中断,通过总线把电信号发送给中断控制器。
上一篇文章中《图解Linux网络包接收过程》,我们梳理了在Linux系统下一个数据包被接收的整个过程。Linux内核对网络包的接收过程大致可以分为接收到RingBuffer、硬中断处理、ksoftirqd软中断处理几个过程。其中在ksoftirqd软中断处理中,把数据包从RingBuffer中摘下来,送到协议栈的处理,再之后送到用户进程socket的接收队列中。
通过前面的文章我们已经了解了「数据包从HTTP层->TCP层->IP层->网卡->互联网->目的地服务器」这中间涉及的知识。
实时系统要求对事件的响应时间不能超过规定的期限,响应时间是指从某个事件发生到负责处理这个事件的进程处理完成的时间间隔,最大响应时间应该是确定的、可以预测的。
今天分享一篇经典Linux协议栈文章,主要讲解Linux网络子系统,看完相信大家对协议栈又会加深不少,不光可以了解协议栈处理流程,方便定位问题,还可以学习一下怎么去设计一个可扩展的子系统,屏蔽不同层次的差异。
假设现在一家公司就有一名客服人员,这个客服人员就有一台座机,这种情况下用户碰到问题只能打电话给这个客服人员,如果有多个用户同时打入只能凭运气,先打通电话的人得到回答,其他人只能依次等待。显然这种处理机制是非常低效的,小公司可能还可以,大一点的公司就不行了。于是现在共有4-5位客服人员,建立总分机架构,1位负责总机(也可以交给语音提示来操作),负责把问题分给4个分机,让4个分机人员来处理具体的问题,这样一来效率就明显提高了。如果客户来电,总机负责人接电话分给分机人员(或通过语音提示用户拨打分机号)叫做硬中断,而分机负责人处理具体问题叫做软中断。Linux的CPU正是采用硬中断与软中断结合的方式来处理问题的。比如现在网卡告诉CPU,有一批数据要从网络中过来,希望系统做好接收准备,CPU手头的工作被打断(中断),将网络上的数据存储在寄存器中,然后呼起一个进程来处理后续操作,就回头处理刚才中断之前的工作了。被呼起的进程可以在后台“慢慢地”地把寄存器中的数据按照规定格式写入数据库中。这里CPU处理的过程就为硬中断过程,而进程把数据写入数据库中过程为软中断过程。具体如图3-19所示。
每一种技术的出现必然是因为某种需求。正因为人的本性是贪婪的,所以科技的创新才能日新月异。
最近,某团外卖被爆出大数据杀熟,所谓的大数据杀熟指的是平台利用户的数据,分析你是否是钱多的人,或者是否是不纠结价格的人,如果是,那么你买同样的物品会比普通用户贵一点,一般这种没有特地去对比价格是很难发现的,所以平台就利用了这点额外赚一些钱。说来很可笑,我们作为平台的资深用户,竟然被平台背后偷偷捞一笔。
1、CPU使用率不高但是软中断已经到了10%,从非idle状态的全部用在了软中断上面。
因为要对百万、千万、甚至是过亿的用户提供各种网络服务,所以在一线互联网企业里面试和晋升后端开发同学的其中一个重点要求就是要能支撑高并发,要理解性能开销,会进行性能优化。而很多时候,如果你对Linux底层的理解不深的话,遇到很多线上性能瓶颈你会觉得狗拿刺猬,无从下手。
比如说你订了一份外卖,但是不确定外卖什么时候送到,也没有别的方法了解外卖的进度, 但是,配送员送外卖是不等人的,到了你这儿没人取的话,就直接走人了;所以你只能苦苦等着,时不时去门口看看外卖送到没,而不能干其他事情;不过呢,如果在订外卖的时候,你就跟配送员约定好,让他送到后给你打个电话,那你就不用苦苦等待了,就可以去忙别的事情,直到电话一响,接电话、取外卖就可以了、
因为要对百万、千万、甚至是过亿的用户提供各种网络服务,所以在一线互联网企业里面试和晋升后端开发同学的其中一个重点要求就是要能支撑高并发,要理解性能开销,会进行性能优化。而很多时候,如果你对网络底层的理解不深的话,遇到很多线上性能瓶颈你会觉得狗拿刺猬,无从下手。
本文将介绍在Linux系统中,以一个UDP包的接收过程作为示例,介绍数据包是如何一步一步从网卡传到进程手中的。
今天分享一位同学的腾讯天美面经,对的就是那个王者荣耀部门的天美,问的问题很细节,会追着基础问题一直深问,直到你不会,才会换话题,主要注重计算机基础,操作系统这方面了。
在支持可抢占的系统中,一个进程的therad_info信息定义如上。其中preempt_count代表的是该进程是否可以被抢占,根据注释的说明当peermpt_count等于0的时候当前进程就可以被抢占,当小于0存在bug,当不等于0也就是大于0说明当前进程不可以被抢占。不可抢占的原因很多,比如当前进程在中断上下文中或者使用了锁(spin_lock的过程中会disable掉抢占的)。至于当前是什么原因不能被抢占,就需要看peermpt_count每个字段的含义。
https://www.cnblogs.com/poloyy/category/1814570.html
在之前的文章中,讲解中断处理相关的概念的时候,提到过有些任务不是紧急的,可以延后一段时间执行。因为中断服务例程都是顺序执行的,在响应一个中断的时候不应该被打断。相反,这些可延时任务执行时,可以使能中断。那么,将这些任务从中断处理程序中剥离出来,可以有效地保证内核对于中断响应时间尽可能短。这对于时间苛刻的应用来说,这是一个很重要的属性,尤其是那些要求中断请求必须在毫秒级别响应的应用。
负载为1表示当前单核CPU全部占用,如果一台机器有3个CPU,每个CPU都是双核的,这是负载最大值为1×2×3=6。如果5分钟以及15分钟的负载指标的大于CPU个数×CPU核数×0.7,并且长时间比较高,说明CPU不够用。
死锁指两个或更多进程或线程因相互等待对方释放资源而互相阻塞,从而导致系统中所有的进程或线程都无法继续运行的情况。
好文推荐 Linux shell编程常用方法总结 C++基础知识精髓 Linux下AutoMake创建工程流程 Qt5.7.1添加支持openssl zynq平台移植python3.10.5 作为一名Linux软件攻城狮,top命令大家应该并不陌生。top命令是Linux下常用的性能分析工具,能够实时显示系统中各个进程的资源占用状况。top可以动态显示过程,不断刷新当前状态。top命令提供了实时的对系统处理器的状态监视。它将显示系统中的任务列表,内存使用和执行时间对任务进行排序。 1、top命令的使用方式
在现代操作系统里,同一时间可能有多个内核执行流在执行,因此内核其实像多进程多线程编程一样也需要一些同步机制来同步各执行单元对共享数据的访问,尤其是在多处理器系统上,更需要一些同步机制来同步不同处理器上的执行单元对共享的数据的访问。在主流的Linux内核中包含了如下这些同步机制包括:
首先,先上DragonOS的GitHub链接:https://github.com/fslongjin/DragonOS
us(user):表示 CPU 在用户运行的时间百分比,通常用户 CPU 高表示有应用程序比较繁忙。典型的用户程序有:数据库、Web 服务器等。
Linux 内核中的同步机制:原子操作、信号量、读写信号量、自旋锁的API、大内核锁、读写锁、大读者锁、RCU和顺序锁。 1、介绍 在现代操作系统里,同一时间可能有多个内核执行流在执行,即使单CPU内核也需要一些同步机制来同步不同执行单元对共享的数据的访问。 主流的Linux内核中的同步机制包括: 原子操作 信号量(semaphore) 读写信号量(rw_semaphore) 自旋锁spinlock 大内核锁BKL(Big Kernel Lock) 读写锁rwlock、 brlock(只包含在2.4内核中
查看CPU使用 在 Linux 系统下,使用 top 命令查看 CPU 使用情况。
黑客通过应用程序的漏洞(如Java、PHP、Apache、IE、Chrome、Adobe、office等)获得执行代码能力后,由于操作系统安全方面的设定,很多情况下都是在沙盒或者低权限进程中运行,许多操作都无法进行。要想做更多高权限的事情,黑客通常会使用工具来提权。
最近在一个客户的项目拓展和做过程中,希望客户在IDC中自建的容器服务能够部分使用云上的容器服务,基于IDC环境和虚拟机上的容器服务之间,做了一些静态和动态的性能对比测试。测试过程终于到一些问题,针对问题前后经过多轮分析对比,在问题定位和分析上的一些总结,希望能供大家借鉴。
之前记录过处理因为 LVS 网卡流量负载过高导致软中断发生丢包的问题,RPS 和 RFS 网卡多队列性能调优实践[1],对一般人来说压力不大的情况下其实碰见的概率并不高。这次想分享的话题是比较常见服务器网卡丢包现象排查思路,如果你是想了解点对点的丢包解决思路涉及面可能就比较广,不妨先参考之前的文章如何使用 MTR 诊断网络问题[2],对于 Linux 常用的网卡丢包分析工具自然是 ethtool。
/proc/cpuinfo是可以获取系统CPU信息比如物理CPU的个数 每个CPU的物理核心数量 CPU的型号和主频等信息。
load average: 0.00, 0.00, 0.00 系统负载,即任务队列的平均长度。 三个数值分别为 1分钟、5分钟、15分钟前到现在的平均值。
自旋锁与互斥锁有点类似,只是自旋锁不会引起调用者睡眠,如果自旋锁已经被别的执行单元保持,调用者就一直循环在那里看是否该自旋锁的保持者已经释放了锁,"自旋"一词就是因此而得名。
半年前我以源码的方式描述了网络包的接收过程。之后不断有粉丝提醒我还没聊发送过程呢。好,安排!
这里深度理解一下在Linux下网络包的接收过程,为了简单起见,我们用udp来举例,如下:
https://www.cnblogs.com/poloyy/category/1746599.html
Redis 服务端的总体请求量从年初最开始日访问量百亿次级别上涨到高峰时段的万亿次级别,给运维和架构团队都带来了极大的挑战。
这些问题虽然在线上经常看到,但我们似乎很少去深究。如果真的能透彻地把这些问题理解到位,我们对性能的掌控能力将会变得更强。
领取专属 10元无门槛券
手把手带您无忧上云