linux软中断查看

❶ linux下怎么查看cpu运行状态

输入命令top-n1|grepCpu

us 用户空间占用CPU的百分比。

sy 内核空间占用CPU的百分比。

ni 改变过优先级的进程占用CPU的百分比

id 空闲CPU百分比

wa IO等待占用CPU的百分比

hi 硬中断（HardwareIRQ）占用CPU的百分比

si 软中断（SoftwareInterrupts）占用CPU的百分比

❷ linux系统的软中断的中断事件有哪些

软中断就是信号中断，能发送信号的事件就能发送中断，比如键盘中断SIGINT，SIGTSTP，SIGSTOP, 时钟中断SIGALRM,浮点中断等等

❸ Manjaro Linux如何查看C P U占用了

cat /proc/cpuinfo |grep cores |wc -l
lscpu
查看cpu使用率：top
第三行：CPU信息

0.0%us【user space】— 用户空间占用CPU的百分比。

0.3%sy【sysctl】— 内核空间占用CPU的百分比。

0.0%ni【】— 改变过优先级的进程占用CPU的百分比

99.7%id【idolt】— 空闲CPU百分比

0.0%wa【wait】— IO等待占用CPU的百分比

0.0%hi【Hardware IRQ】— 硬中断占用CPU的百分比

0.0%si【Software Interrupts】— 软中断占用CPU的百分比

❹ 系统的软中断CPU使用率升高，我该怎么办

[TOC]
上一期我给你讲了软中断的基本原理，我们先来简单复习下。

中断是一种异步的事件处理机制，用来提高系统的并发处理能力。中断事件发生，会触发执行中断处理程序，而中断处理程序被分为上半部和下半部这两个部分。

Linux 中的软中断包括网络收发、定时、调度、RCU 锁等各种类型，我们可以查看 proc 文件系统中的 /proc/softirqs ，观察软中断的运行情况。

在 Linux 中，每个 CPU 都对应一个软中断内核线程，名字是 ksoftirqd/CPU 编号。当软中断事件的频率过高时，内核线程也会因为 CPU 使用率过高而导致软中断处理不及时，进而引发网络收发延迟、调度缓慢等性能问题。

软中断 CPU 使用率过高也是一种最常见的性能问题。今天，我就用最常见的反向代理服务器 Nginx 的案例，教你学会分析这种情况。

接下来的案例基于 Ubuntu 18.04，也同样适用于其他的 Linux 系统。我使用的案例环境是这样的：

这里我又用到了三个新工具，sar、 hping3 和 tcpmp，先简单介绍一下：

本次案例用到两台虚拟机，我画了一张图来表示它们的关系。

你可以看到，其中一台虚拟机运行 Nginx ，用来模拟待分析的 Web 服务器；而另一台当作 Web 服务器的客户端，用来给 Nginx 增加压力请求。使用两台虚拟机的目的，是为了相互隔离，避免“交叉感染”。

接下来，我们打开两个终端，分别 SSH 登录到两台机器上，并安装上面提到的这些工具。

同以前的案例一样，下面的所有命令都默认以 root 用户运行，如果你是用普通用户身份登陆系统，请运行 sudo su root 命令切换到 root 用户。

安装完成后，我们先在第一个终端，执行下面的命令运行案例，也就是一个最基本的 Nginx 应用：

然后，在第二个终端，使用 curl 访问 Nginx 监听的端口，确认 Nginx 正常启动。假设 192.168.58.99 是 Nginx 所在虚拟机的 IP 地址，运行 curl 命令后你应该会看到下面这个输出界面：

接着，还是在第二个终端，我们运行 hping3 命令，来模拟 Nginx 的客户端请求：

现在我们再回到第一个终端，你应该发现了异常。是不是感觉系统响应明显变慢了，即便只是在终端中敲几个回车，都得很久才能得到响应？这个时候应该怎么办呢？

虽然在运行 hping3 命令时，我就已经告诉你，这是一个 SYN FLOOD 攻击，你肯定也会想到从网络方面入手，来分析这个问题。不过，在实际的生产环境中，没人直接告诉你原因。

所以，我希望你把 hping3 模拟 SYN FLOOD 这个操作暂时忘掉，然后重新从观察到的问题开始，分析系统的资源使用情况，逐步找出问题的根源。

那么，该从什么地方入手呢？刚才我们发现，简单的 SHELL 命令都明显变慢了，先看看系统的整体资源使用情况应该是个不错的注意，比如执行下 top 看看是不是出现了 CPU 的瓶颈。我们在第一个终端运行 top 命令，看一下系统整体的资源使用情况。

这里你有没有发现异常的现象？我们从第一行开始，逐个看一下：

那为什么系统的响应变慢了呢？既然每个指标的数值都不大，那我们就再来看看，这些指标对应的更具体的含义。毕竟，哪怕是同一个指标，用在系统的不同部位和场景上，都有可能对应着不同的性能问题。

仔细看 top 的输出，两个 CPU 的使用率虽然分别只有 3.3% 和 4.4%，但都用在了软中断上；而从进程列表上也可以看到，CPU 使用率最高的也是软中断进程 ksoftirqd。看起来，软中断有点可疑了。

根据上一期的内容，既然软中断可能有问题，那你先要知道，究竟是哪类软中断的问题。停下来想想，上一节我们用了什么方法，来判断软中断类型呢？没错，还是 proc 文件系统。观察 /proc/softirqs 文件的内容，你就能知道各种软中断类型的次数。

不过，这里的各类软中断次数，又是什么时间段里的次数呢？它是系统运行以来的累积中断次数。所以我们直接查看文件内容，得到的只是累积中断次数，对这里的问题并没有直接参考意义。因为，这些中断次数的变化速率才是我们需要关注的。

那什么工具可以观察命令输出的变化情况呢？我想你应该想起来了，在前面案例中用过的 watch 命令，就可以定期运行一个命令来查看输出；如果再加上 -d 参数，还可以高亮出变化的部分，从高亮部分我们就可以直观看出，哪些内容变化得更快。

比如，还是在第一个终端，我们运行下面的命令：

通过 /proc/softirqs 文件内容的变化情况，你可以发现， TIMER（定时中断）、NET_RX（网络接收）、SCHED（内核调度）、RCU（RCU 锁）等这几个软中断都在不停变化。

其中，NET_RX，也就是网络数据包接收软中断的变化速率最快。而其他几种类型的软中断，是保证 Linux 调度、时钟和临界区保护这些正常工作所必需的，所以它们有一定的变化倒是正常的。

那么接下来，我们就从网络接收的软中断着手，继续分析。既然是网络接收的软中断，第一步应该就是观察系统的网络接收情况。这里你可能想起了很多网络工具，不过，我推荐今天的主人公工具 sar 。

sar 可以用来查看系统的网络收发情况，还有一个好处是，不仅可以观察网络收发的吞吐量（BPS，每秒收发的字节数），还可以观察网络收发的 PPS，即每秒收发的网络帧数。

我们在第一个终端中运行 sar 命令，并添加 -n DEV 参数显示网络收发的报告：

对于 sar 的输出界面，我先来简单介绍一下，从左往右依次是：

我们具体来看输出的内容，你可以发现：

从这些数据，你有没有发现什么异常的地方？

既然怀疑是网络接收中断的问题，我们还是重点来看 eth0 ：接收的 PPS 比较大，达到 12607，而接收的 BPS 却很小，只有 664 KB。直观来看网络帧应该都是比较小的，我们稍微计算一下，664*1024/12607 = 54 字节，说明平均每个网络帧只有 54 字节，这显然是很小的网络帧，也就是我们通常所说的小包问题。

那么，有没有办法知道这是一个什么样的网络帧，以及从哪里发过来的呢？

使用 tcpmp 抓取 eth0 上的包就可以了。我们事先已经知道， Nginx 监听在 80 端口，它所提供的 HTTP 服务是基于 TCP 协议的，所以我们可以指定 TCP 协议和 80 端口精确抓包。

接下来，我们在第一个终端中运行 tcpmp 命令，通过 -i eth0 选项指定网卡 eth0，并通过 tcp port 80 选项指定 TCP 协议的 80 端口：

从 tcpmp 的输出中，你可以发现

再加上前面用 sar 发现的， PPS 超过 12000 的现象，现在我们可以确认，这就是从 192.168.0.2 这个地址发送过来的 SYN FLOOD 攻击。

到这里，我们已经做了全套的性能诊断和分析。从系统的软中断使用率高这个现象出发，通过观察 /proc/softirqs 文件的变化情况，判断出软中断类型是网络接收中断；再通过 sar 和 tcpmp ，确认这是一个 SYN FLOOD 问题。

SYN FLOOD 问题最简单的解决方法，就是从交换机或者硬件防火墙中封掉来源 IP，这样 SYN FLOOD 网络帧就不会发送到服务器中。

案例结束后，也不要忘了收尾，记得停止最开始启动的 Nginx 服务以及 hping3 命令。

在第一个终端中，运行下面的命令就可以停止 Nginx 了：

软中断 CPU 使用率（softirq）升高是一种很常见的性能问题。虽然软中断的类型很多，但实际生产中，我们遇到的性能瓶颈大多是网络收发类型的软中断，特别是网络接收的软中断。

在碰到这类问题时，你可以借用 sar、tcpmp 等工具，做进一步分析。

有同学说在查看软中断数据时会显示128个核的数据，我的也是，虽然只有一个核，但是会显示128个核的信息，用下面的命令可以提取有数据的核，我的1核，所以这个命令只能显示1核，多核需要做下修改

watch -d "/bin/cat /proc/softirqs | /usr/bin/awk 'NR == 1{printf "%13s %s\n"," ",$1}; NR > 1{printf "%13s %s\n",$1,$2}'"

❺ 如何查看linux软中断信息

先说说环境1.硬件:DELL R410
2.网卡:板载1000M BCM5709
2.OS: RHEL 5.5 x86_64
3.KERNEL: 2.6.18-194.el5
所出现的问题
1.网卡毫无征兆的down掉，而且没有任何log信息
2.当流量增大时，不到理论上限的1/3时机器出现网络延迟严重，伴随大量的丢包
3.机器的cpu软中断不均衡，只有1个cpu处理软中断，并且该cpu的软中断周期性的达到100%
4.内外网网卡做nat丢包数据量不一致，差别很大，不在同一个数量级
想必第一个问题，大部分使用bcm网卡，rhel 5.3以后得机器都会遇到这种情况，网上的资料比较的多，我也不多啰嗦了，直接升级网卡驱动就可以解决了。第二，三，四其实是同一个问题都是由于网卡中断过多，cpu处理不过来(准确的说，cpu分配不均衡，导致只有一个cpu处理，处理不过来)，引起丢包，那么为什么两个网卡丢包的数量级不一样呢，下面从原理上进行解释，既然是做nat多出口，那么就有大量的路由信息，是一个网络应用，当一个数据包请求nat时，数据包先被网卡驱动的数据接收，网卡收到数据时，触发中断。在中断执行例程中，把skb挂入输入队列，并触发软中断。稍后的某个时刻，当软中断执行时，再从该队列中把skb取下来，投递给上层协议。

❻ Linux-怎么理解软中断

中断是系统用来响应硬件设备请求的一种机制，它会打断进程的正常调度和执行，然后调用内核中的中断处理程序来响应设备的请求。

你可能要问了，为什么要有中断呢？我可以举个生活中的例子，让感受一下中断的魅力。

比如你订了一份外卖，但是不确定外卖什么时候送到，也没有别的方法了解外卖的进度，但是，配送员送外卖是不等人的，到了你这儿没人取的话，就直接走人了，所以你只能苦苦等着，时不时去门口看看外卖送到没，而不能干其他事情。

不过呢，如果在订外卖的时候，你就跟配送员约定好，让他送到后给你打个电话，那你就不用苦苦等待了，就可以去忙别的事情，直到电话一响，接电话、取外卖就可以了。

这里的“打电话”，其实就是一个中断。没接到电话的时候，你可以做其他的事情；只有接到了电话（也就是发生中断），你才要进行另一个动作：取外卖。

这个例子你就可以发现， 中断其实是一种异步的事件处理机制，可以提高系统的并发处理能力。

由于中断处理程序会打断其他进程的运行，所以， 为了减少对正常进程运行调度的影响，中断处理程序就需要尽可能快地运行。 如果中断本身要做的事情不多，那么处理起来也不会有太大问题；但如果中断要处理的事情很多，中断服务程序就有可能要运行很长时间。

特别是，中断处理程序在响应中断时，还会临时关闭中断。这就会导致上一次中断处理完成之前，其他中断都不能响应，也就是说中断有可能会丢失。

那么还是以取外卖为例。假如你订了 2 份外卖，一份主食和一份饮料，并且是由 2 个不同的配送员来配送。这次你不用时时等待着，两份外卖都约定了电话取外卖的方式。但是，问题又来了。

当第一份外卖送到时，配送员给你打了个长长的电话，商量发票的处理方式。与此同时，第二个配送员也到了，也想给你打电话。

但是很明显，因为电话占线（也就是关闭了中断响应），第二个配送员的电话是打不通的。所以，第二个配送员很可能试几次后就走掉了（也就是丢失了一次中断）。

如果你弄清楚了“取外卖”的模式，那对系统的中断机制就很容易理解了。事实上，为了解决中断处理程序执行过长和中断丢失的问题，Linux 将中断处理过程分成了两个阶段，也就是 上半部和下半部：

比如说前面取外卖的例子，上半部就是你接听电话，告诉配送员你已经知道了，其他事儿见面再说，然后电话就可以挂断了；下半部才是取外卖的动作，以及见面后商量发票处理的动作。

这样，第一个配送员不会占用你太多时间，当第二个配送员过来时，照样能正常打通你的电话。

除了取外卖，我再举个最常见的网卡接收数据包的例子，让你更好地理解。

网卡接收到数据包后，会通过 硬件中断 的方式，通知内核有新的数据到了。这时，内核就应该调用中断处理程序来响应它。你可以自己先想一下，这种情况下的上半部和下半部分别负责什么工作呢？

对上半部来说，既然是快速处理，其实就是要把网卡的数据读到内存中，然后更新一下硬件寄存器的状态（表示数据已经读好了），最后再发送一个 软中断 信号，通知下半部做进一步的处理。

而下半部被软中断信号唤醒后，需要从内存中找到网络数据，再按照网络协议栈，对数据进行逐层解析和处理，直到把它送给应用程序。

所以，这两个阶段你也可以这样理解：

实际上，上半部会打断 CPU 正在执行的任务，然后立即执行中断处理程序。而下半部以内核线程的方式执行，并且每个 CPU 都对应一个软中断内核线程，名字为 “ksoftirqd/CPU 编号”，比如说， 0 号 CPU 对应的软中断内核线程的名字就是 ksoftirqd/0。

不过要注意的是，软中断不只包括了刚刚所讲的硬件设备中断处理程序的下半部，一些内核自定义的事件也属于软中断，比如内核调度和 RCU 锁（Read-Copy Update 的缩写，RCU 是 Linux 内核中最常用的锁之一）等。

不知道你还记不记得，前面提到过的 proc 文件系统。它是一种内核空间和用户空间进行通信的机制，可以用来查看内核的数据结构，或者用来动态修改内核的配置。其中：

运行下面的命令，查看 /proc/softirqs 文件的内容，你就可以看到各种类型软中断在不同 CPU 上的累积运行次数：

在查看 /proc/softirqs 文件内容时，你要特别注意以下这两点。
第一，要注意软中断的类型，也就是这个界面中第一列的内容。从第一列你可以看到，软中断包括了 10 个类别，分别对应不同的工作类型。比如 NET_RX 表示网络接收中断，而 NET_TX 表示网络发送中断。

第二，要注意同一种软中断在不同 CPU 上的分布情况，也就是同一行的内容。正常情况下，同一种中断在不同 CPU 上的累积次数应该差不多。比如这个界面中，NET_RX 在 CPU0 和 CPU1 上的中断次数基本是同一个数量级，相差不大。

不过你可能发现，TASKLET 在不同 CPU 上的分布并不均匀。TASKLET 是最常用的软中断实现机制，每个 TASKLET 只运行一次就会结束 ，并且只在调用它的函数所在的 CPU 上运行。

因此，使用 TASKLET 特别简便，当然也会存在一些问题，比如说由于只在一个 CPU 上运行导致的调度不均衡，再比如因为不能在多个 CPU 上并行运行带来了性能限制。

另外，刚刚提到过，软中断实际上是以内核线程的方式运行的，每个 CPU 都对应一个软中断内核线程，这个软中断内核线程就叫做 ksoftirqd/CPU 编号。那要怎么查看这些线程的运行状况呢？

其实用 ps 命令就可以做到，比如执行下面的指令：

注意，这些线程的名字外面都有中括号，这说明 ps 无法获取它们的命令行参数（cmline）。一般来说，ps 的输出中，名字括在中括号里的，一般都是内核线程。

Linux 中的中断处理程序分为上半部和下半部：
上半部对应硬件中断，用来快速处理中断。
下半部对应软中断，用来异步处理上半部未完成的工作。

Linux 中的软中断包括网络收发、定时、调度、RCU 锁等各种类型，可以通过查看 /proc/softirqs 来观察软中断的运行情况。

❼ linux怎样使用top命令查看系统状态

top命令是Linux下常用的性能分析工具，能够实时显示系统中各个进程的资源占用状况，类似于Windows的任务管理器。
top显示系统当前的进程和其他状况,是一个动态显示过程,即可以通过用户按键来不断刷新当前状态.如果在前台执行该命令,它将独占前台,直到用户终止该程序为止. 比较准确的说,top命令提供了实时的对系统处理器的状态监视.它将显示系统中CPU最“敏感”的任务列表.该命令可以按CPU使用.内存使用和执行时间对任务进行排序；而且该命令的很多特性都可以通过交互式命令或者在个人定制文件中进行设定.
下面详细介绍它的使用方法。
统计信息区前五行是系统整体的统计信息。第一行是任务队列信息，同 uptime 命令的执行结果。其内容如下：
01:06:48 当前时间
up 1:22 系统运行时间，格式为时:分
1 user 当前登录用户数
load average: 0.06, 0.60, 0.48 系统负载，即任务队列的平均长度。三个数值分别为 1分钟、5分钟、15分钟前到现在的平均值。

第二、三行为进程和CPU的信息。当有多个CPU时，这些内容可能会超过两行。内容如下：

total 进程总数
running 正在运行的进程数
sleeping 睡眠的进程数
stopped 停止的进程数
zombie 僵尸进程数
Cpu(s):
0.3% us 用户空间占用CPU百分比
1.0% sy 内核空间占用CPU百分比
0.0% ni 用户进程空间内改变过优先级的进程占用CPU百分比
98.7% id 空闲CPU百分比
0.0% wa 等待输入输出的CPU时间百分比
0.0%hi：硬件CPU中断占用百分比
0.0%si：软中断占用百分比
0.0%st：虚拟机占用百分比

最后两行为内存信息。内容如下：

Mem:
191272k total 物理内存总量
173656k used 使用的物理内存总量
17616k free 空闲内存总量
22052k buffers 用作内核缓存的内存量
Swap:
192772k total 交换区总量
0k used 使用的交换区总量
192772k free 空闲交换区总量
123988k cached 缓冲的交换区总量,内存中的内容被换出到交换区，而后又被换入到内存，但使用过的交换区尚未被覆盖，该数值即为这些内容已存在于内存中的交换区的大小,相应的内存再次被换出时可不必再对交换区写入。

进程信息区统计信息区域的下方显示了各个进程的详细信息。首先来认识一下各列的含义。

序号 列名 含义
a PID 进程id
b PPID 父进程id
c RUSER Real user name
d UID 进程所有者的用户id
e USER 进程所有者的用户名
f GROUP 进程所有者的组名
g TTY 启动进程的终端名。不是从终端启动的进程则显示为 ?
h PR 优先级
i NI nice值。负值表示高优先级，正值表示低优先级
j P 最后使用的CPU，仅在多CPU环境下有意义
k %CPU 上次更新到现在的CPU时间占用百分比
l TIME 进程使用的CPU时间总计，单位秒
m TIME+ 进程使用的CPU时间总计，单位1/100秒
n %MEM 进程使用的物理内存百分比
o VIRT 进程使用的虚拟内存总量，单位kb。VIRT=SWAP+RES
p SWAP 进程使用的虚拟内存中，被换出的大小，单位kb。
q RES 进程使用的、未被换出的物理内存大小，单位kb。RES=CODE+DATA
r CODE 可执行代码占用的物理内存大小，单位kb
s DATA 可执行代码以外的部分(数据段+栈)占用的物理内存大小，单位kb
t SHR 共享内存大小，单位kb
u nFLT 页面错误次数
v nDRT 最后一次写入到现在，被修改过的页面数。
w S 进程状态(D=不可中断的睡眠状态,R=运行,S=睡眠,T=跟踪/停止,Z=僵尸进程)
x COMMAND 命令名/命令行
y WCHAN 若该进程在睡眠，则显示睡眠中的系统函数名
z Flags 任务标志，参考 sched.h

默认情况下仅显示比较重要的 PID、USER、PR、NI、VIRT、RES、SHR、S、%CPU、%MEM、TIME+、COMMAND 列。可以通过下面的快捷键来更改显示内容。
更改显示内容通过 f 键可以选择显示的内容。按 f 键之后会显示列的列表，按 a-z 即可显示或隐藏对应的列，最后按回车键确定。
按 o 键可以改变列的显示顺序。按小写的 a-z 可以将相应的列向右移动，而大写的 A-Z 可以将相应的列向左移动。最后按回车键确定。
按大写的 F 或 O 键，然后按 a-z 可以将进程按照相应的列进行排序。而大写的 R 键可以将当前的排序倒转。

命令使用
top使用格式
top [-] [d] [p] [q] [c] [C] [S] [s] [n]

参数说明

d 指定每两次屏幕信息刷新之间的时间间隔。当然用户可以使用s交互命令来改变之。
p 通过指定监控进程ID来仅仅监控某个进程的状态。
q 该选项将使top没有任何延迟的进行刷新。如果调用程序有超级用户权限，那么top将以尽可能高的优先级运行。
S 指定累计模式
s 使top命令在安全模式中运行。这将去除交互命令所带来的潜在危险。
i 使top不显示任何闲置或者僵死进程。
c 显示整个命令行而不只是显示命令名

其他实用命令
下面介绍在top命令执行过程中可以使用的一些交互命令。从使用角度来看，熟练的掌握这些命令比掌握选项还重要一些。这些命令都是单字母的，如果在命令行选项中使用了s选项，则可能其中一些命令会被屏蔽掉。

Ctrl+L 擦除并且重写屏幕。
h或者? 显示帮助画面，给出一些简短的命令总结说明。
k 终止一个进程。系统将提示用户输入需要终止的进程PID，以及需要发送给该进程什么样的信号。一般的终止进程可以使用15信号；如果不能正常结束那就使用信号9强制结束该进程。默认值是信号15。在安全模式中此命令被屏蔽。
i 忽略闲置和僵死进程。这是一个开关式命令。
q 退出程序。
r 重新安排一个进程的优先级别。系统提示用户输入需要改变的进程PID以及需要设置的进程优先级值。输入一个正值将使优先级降低，反之则可以使该进程拥有更高的优先权。默认值是10。
S 切换到累计模式。
s 改变两次刷新之间的延迟时间。系统将提示用户输入新的时间，单位为s。如果有小数，就换算成m s。输入0值则系统将不断刷新，默认值是5 s。需要注意的是如果设置太小的时间，很可能会引起不断刷新，从而根本来不及看清显示的情况，而且系统负载也会大大增加。
f或者F 从当前显示中添加或者删除项目。
o或者O 改变显示项目的顺序。
l 切换显示平均负载和启动时间信息。
m 切换显示内存信息。
t 切换显示进程和CPU状态信息。
c 切换显示命令名称和完整命令行。
M 根据驻留内存大小进行排序。
P 根据CPU使用百分比大小进行排序。
T 根据时间/累计时间进行排序。
W 将当前设置写入~/.toprc文件中。这是写top配置文件的推荐方法。

附常用操作:
top //每隔5秒显式所有进程的资源占用情况
top -d 2 //每隔2秒显式所有进程的资源占用情况
top -c //每隔5秒显式进程的资源占用情况，并显示进程的命令行参数(默认只有进程名)
top -p 12345 -p 6789//每隔5秒显示pid是12345和pid是6789的两个进程的资源占用情况
top -d 2 -c -p 123456 //每隔2秒显示pid是12345的进程的资源使用情况，并显式该进程启动的命令行参数

❽ linux 内核软中断 是在中断状态吗

先说说环境
1.硬件:DELL R410
2.网卡:板载1000M BCM5709
2.OS: RHEL 5.5 x86_64
3.KERNEL: 2.6.18-194.el5
所出现的问题
1.网卡毫无征兆的down掉，而且没有任何log信息
2.当流量增大时，不到理论上限的1/3时机器出现网络延迟严重，伴随大量的丢包
3.机器的cpu软中断不均衡，只有1个cpu处理软中断，并且该cpu的软中断周期性的达到100%
4.内外网网卡做nat丢包数据量不一致，差别很大，不在同一个数量级
想必第一个问题，大部分使用bcm网卡，rhel 5.3以后得机器都会遇到这种情况，网上的资料比较的多，我也不多啰嗦了，直接升级网卡驱动就可以解决了。第二，三，四其实是同一个问题都是由于网卡中断过多，cpu处理不过来(准确的说，cpu分配不均衡，导致只有一个cpu处理，处理不过来)，引起丢包，那么为什么两个网卡丢包的数量级不一样呢，下面从原理上进行解释，既然是做nat多出口，那么就有大量的路由信息，是一个网络应用，当一个数据包请求nat时，数据包先被网卡驱动的数据接收，网卡收到数据时，触发中断。在中断执行例程中，把skb挂入输入队列，并触发软中断。稍后的某个时刻，当软中断执行时，再从该队列中把skb取下来，投递给上层协议。
如果在这个过程当中cpu没有及时处理完这个队列导致网卡的buffer满了，网卡将直接丢弃该数据包。这里牵涉到2个队列，一个是tx，一个是rx，它的队列的大小默认都是255，可以通过ethtool -g eth0(你指定的网卡)，为了防止丢包，当时我通过ethtool -G eth0 rx xxx 把它调大了，但是调大以后，还是杯水车薪啊，通过ethtool -S eth0 |grep rx_fw_discards,发现数值还是不停的在增长，也就是说还在不停的丢包，cpu处理不过来，这时候找到网上有人在利用lvs时也遇到这个问题，cpu软中断分配不均衡，只有一个cpu处理软中断的问题，网上的资料五花八门，有建议使用修改设备中断方式。即通过修改设置中断/proc/irq/${网卡中断号}/smp_affinit这时候，我也修改过，没有什么实质的效果，
从官方的bug报告，https://bugzilla.redhat.com/show_bug.cgi?id=520888，其中提到rhel5.6已经修复了这个bug，这其中也提到目前我们的版本可以升级内核到kernel-2.6.18-194.3.1.el5可以解决这个问题。
红帽子官方修复报告中的说明如下：http://rhn.redhat.com/errata/RHSA-2010-0398.html，我们升级了这个内核算是解决单核处理软中断的问题，升级后各个cpu已经能够平均的分配这个软中断，也不丢包了，那么为什么cpu处理不过来这个软中断呢，数据量并不是特别的大啊，上层应用接到这个数据包后，通过路由协议，找到某个出口给nat出去，找nat出口是需要查找路由表，查询路由表是一件很耗时的工作，而每一个不同源地址，不同目的地址的数据包都得重新查找一次路由表，导致cpu处理不过来，为了提高路由查询的效率。Linux内核引用了路由缓存，用于减少对路由表的查询。Linux的路由缓存是被设计来与协议无关的独立子系统，查看路由缓存可以通过命令route -Cn,由于路由缓存当中是采用hash算法进行才找，它的查找速度非常之快，既然是cache就有超时这一概念。系统默认为10分钟，可以通过这个文件进行查看和修改/proc/sys/net/ipv4/route/secret_interval。而当路由缓存当中未找到或者已经超时的路由信息才开始查找路由表，查询到的结果保存在路由缓存中。如果路由表越大，那么查询的时间就越长，一个新的连接进来后或者是老连接cache超时后，占用大量的cpu查询时间，导致cpu周期性的软中断出现100%，而两个网卡丢包的情况来看不均衡也是因为用户的数据包是经过其中一个网卡进来后查询路由表耗时过长，cpu处理不过来，导致那块网卡的队列满了，丢包严重。当然在路由表变动不大的情况下可以加大cache的时间，修改上述内容后，从我监测的情况来看，扛流量能力得到了大大的提升。

❾ LINUX软中断通信

我也是初学者，这里抄一段《Linux设备驱动程序》书上的给你：

Linux的中断宏观分为两种：软中断和硬中断。声明一下，这里的软和硬的意思是指和软件相关以及和硬件相关，而不是软件实现的中断或硬件实现的中断。软中断就是“信号机制”。软中断不是软件中断。Linux通过信号来产生对进程的各种中断操作，我们现在知道的信号共有31个，其具体内容这里略过。
一般来说，软中断是由内核机制的触发事件引起的（例如进程运行超时），但是不可忽视有大量的软中断也是由于和硬件有关的中断引起的，例如当打印机端口产生一个硬件中断时，会通知和硬件相关的硬中断，硬中断就会产生一个软中断并送到操作系统内核里，这样内核就会根据这个软中断唤醒睡眠在打印机任务队列中的处理进程。
硬中断就是通常意义上的“中断处理程序”，它是直接处理由硬件发过来的中断信号的。当硬中断收到它应当处理的中断信号以后，就回去自己驱动的设备上去看看设备的状态寄存器以了解发生了什么事情，并进行相应的操作。
对于软中断，我们不做讨论，那是进程调度里要考虑的事情。由于我们讨论的是设备驱动程序的中断问题，所以焦点集中在硬中断里。我们这里讨论的是硬中断，即和硬件相关的中断。
要中断，是因为外设需要通知操作系统她那里发生了一些事情，但是中断的功能仅仅是一个设备报警灯，当灯亮的时候中断处理程序只知道有事情发生了，但发生了什么事情还要亲自到设备那里去看才行。也就是说，当中断处理程序得知设备发生了一个中断的时候，它并不知道设备发生了什么事情，只有当它访问了设备上的一些状态寄存器以后，才能知道具体发生了什么，要怎么去处理。
设备通过中断线向中断控制器发送高电平告诉操作系统它产生了一个中断，而操作系统会从中断控制器的状态位知道是哪条中断线上产生了中断。PC机上使用的中断控制器是8259，这种控制器每一个可以管理8条中断线，当两个8259级联的时候共可以控制15条中断线。这里的中断线是实实在在的电路，他们通过硬件接口连接到CPU外的设备控制器上。
并不是每个设备都可以向中断线上发中断信号的，只有对某一条确定的中断线勇有了控制权，才可以向这条中断线上发送信号。由于计算机的外部设备越来越多，所以15条中断线已经不够用了，中断线是非常宝贵的资源。要使用中断线，就得进行中断线的申请，就是IRQ(Interrupt Requirement)，我们也常把申请一条中断线成为申请一个IRQ或者是申请一个中断号。
IRQ是非常宝贵的，所以我们建议只有当设备需要中断的时候才申请占用一个IRQ，或者是在申请IRQ时采用共享中断的方式，这样可以让更多的设备使用中断。无论对IRQ的使用方式是独占还是共享，申请IRQ的过程都是一样的，分为3步：
1．将所有的中断线探测一遍，看看哪些中断还没有被占用。从这些还没有被占用的中断中选一个作为该设备的IRQ。
2．通过中断申请函数申请选定的IRQ，这是要指定申请的方式是独占还是共享。
3．根据中断申请函数的返回值决定怎么做：如果成功了万事大吉，如果没成功则或者重新申请或者放弃申请并返回错误。
Linux中的中断处理程序很有特色，它的一个中断处理程序分为两个部分：上半部（top half）和下半部(bottom half)。之所以会有上半部和下半部之分，完全是考虑到中断处理的效率。
上半部的功能是“登记中断”。当一个中断发生时，他就把设备驱动程序中中断例程的下半部挂到该设备的下半部执行队列中去，然后就没事情了--等待新的中断的到来。这样一来，上半部执行的速度就会很快，他就可以接受更多她负责的设备产生的中断了。上半部之所以要快，是因为它是完全屏蔽中断的，如果她不执行完，其它的中断就不能被及时的处理，只能等到这个中断处理程序执行完毕以后。所以，要尽可能多得对设备产生的中断进行服务和处理，中断处理程序就一定要快。
但是，有些中断事件的处理是比较复杂的，所以中断处理程序必须多花一点时间才能够把事情做完。可怎么样化解在短时间内完成复杂处理的矛盾呢，这时候 Linux引入了下半部的概念。下半部和上半部最大的不同是下半部是可中断的，而上半部是不可中断的。下半部几乎做了中断处理程序所有的事情，因为上半部只是将下半部排到了他们所负责的设备的中断处理队列中去，然后就什么都不管了。下半部一般所负责的工作是察看设备以获得产生中断的事件信息，并根据这些信息（一般通过读设备上的寄存器得来）进行相应的处理。如果有些时间下半部不知道怎么去做，他就使用着名的鸵鸟算法来解决问题--说白了就是忽略这个事件。
由于下半部是可中断的，所以在它运行期间，如果其它的设备产生了中断，这个下半部可以暂时的中断掉，等到那个设备的上半部运行完了，再回头来运行它。但是有一点一定要注意，那就是如果一个设备中断处理程序正在运行，无论她是运行上半部还是运行下半部，只要中断处理程序还没有处理完毕，在这期间设备产生的新的中断都将被忽略掉。因为中断处理程序是不可重入的，同一个中断处理程序是不能并行的。
在Linux Kernel 2.0以前，中断分为快中断和慢中断（伪中断我们这里不谈），其中快中断的下半部也是不可中断的，这样可以保证它执行的快一点。但是由于现在硬件水平不断上升，快中断和慢中断的运行速度已经没有什么差别了，所以为了提高中断例程事务处理的效率，从Linux kernel 2.0以后，中断处理程序全部都是慢中断的形式了--他们的下半部是可以被中断的。
但是，在下半部中，你也可以进行中断屏蔽--如果某一段代码不能被中断的话。你可以使用cti、sti或者是save_flag、restore_flag来实现你的想法。
在处理中断的时候，中断控制器会屏蔽掉原先发送中断的那个设备，直到她发送的上一个中断被处理完了为止。因此如果发送中断的那个设备载中断处理期间又发送了一个中断，那么这个中断就被永远的丢失了。
之所以发生这种事情，是因为中断控制器并不能缓冲中断信息，所以当前一个中断没有处理完以前又有新的中断到达，他肯定会丢掉新的中断的。但是这种缺陷可以通过设置主处理器(CPU)上的“置中断标志位”（sti）来解决，因为主处理器具有缓冲中断的功能。如果使用了“置中断标志位”，那么在处理完中断以后使用sti函数就可以使先前被屏蔽的中断得到服务。
有时候需要屏蔽中断，可是为什么要将这个中断屏蔽掉呢？这并不是因为技术上实现不了同一中断例程的并行，而是出于管理上的考虑。之所以在中断处理的过程中要屏蔽同一IRQ来的新中断，是因为中断处理程序是不可重入的，所以不能并行执行同一个中断处理程序。在这里我们举一个例子，从这里子例中可以看出如果一个中断处理程序是可以并行的话，那么很有可能会发生驱动程序锁死的情况。当驱动程序锁死的时候，你的操作系统并不一定会崩溃，但是锁死的驱动程序所支持的那个设备是不能再使用了--设备驱动程序死了，设备也就死了。
A是一段代码，B是操作设备寄存器R1的代码，C是操作设备寄存器R2的代码。其中激发PS1的事件会使A1产生一个中断，然后B1去读R1中已有的数据，然后代码C1向R2中写数据。而激发PS2的事件会使A2产生一个中断，然后B2删除R1中的数据，然后C2读去R2中的数据。
如果PS1先产生，且当他执行到A1和B1之间的时候，如果PS2产生了，这是A2会产生一个中断，将PS2中断掉（挂到任务队列的尾部），然后删除了 R1的内容。当PS2运行到C2时，由于C1还没有向R2中写数据，所以C2将会在这里被挂起，PS2就睡眠在代码C2上，直到有数据可读的时候被信号唤醒。这是由于PS1中的B2原先要读的R1中的数据被PS2中的B2删除了，所以PS1页会睡眠在B1上，直到有数据可读的时候被信号唤醒。这样一来，唤醒PS1和PS2的事件就永远不会发生了，因此PS1和PS2之间就锁死了。
由于设备驱动程序要和设备的寄存器打交道，所以很难写出可以重入的代码来，因为设备寄存器就是全局变量。因此，最简洁的办法就是禁止同一设备的中断处理程序并行，即设备的中断处理程序是不可重入的。
有一点一定要清楚：在2.0版本以后的Linux kernel中，所有的上半部都是不可中断的（上半部的操作是原子性的）；不同设备的下半部可以互相中断，但一个特定的下半部不能被它自己所中断（即同一个下半部不能并）。
由于中断处理程序要求不可重入，所以程序员也不必为编写可重入的代码而头痛了。编写可重入的设备驱动程序是可以的，编写可重入的中断处理程序是非常难得，几乎不可能。
我们都知道，一旦竞争条件出现了，就有可能会发生死锁的情况，严重时可能会将整个系统锁死。所以一定要避免竞争条件的出现。只要注意一点：绝大多数由于中断产生的竞争条件，都是在带有中断的
内核进程被睡眠造成的。所以在实现中断的时候，一定要相信谨慎的让进程睡眠，必要的时候可以使用cli、sti或者save_flag、restore_flag。