Linux性能优化从入门到实战:05 CPU篇:硬中断、软中断

??软中断(softirq)会导致CPU 使用率升高

??中断是系统用来响应硬件设备请求的一种机制,它会打断进程的正常调度和执行,然后调用内核中的中断处理程序来响应设备的请求。中断其实是一种异步的事件处理机制,可以提高系统的并发处理能力。由于中断处理程序会打断其他进程的运行,所以,为了减少对正常进程运行调度的影响,中断处理程序就需要尽可能快地运行。并且当CPU执行在中断处理函数中时,不会响应同时发生的又一次中断。

??所以为了加快中断处理程序执行和解决中断丢失的问题,Linux将中断分为上半部和下半部。
??上半部硬中断,用来快速处理中断,它在中断禁止模式下运行,主要处理跟硬件紧密相关的或时间敏感的工作,会打断 CPU 正在执行的任务。
??下半部软中断,用来延迟处理上半部未完成的工作,通常由内核触发,以内核线程的方式运行。并且每个 CPU 都对应一个软中断内核线程,名字为 “ksoftirqd/” 。软中断不仅包括硬件处理程序的下半部,还包括一些内核自定义的事件,比如内核调度、RCU 锁(Read-Copy Update)、网络收发、定时等。
??如:网卡接收数据的过程。对上半部来说,是把网卡的数据读到内存中,然后更新一下硬件寄存器的状态,再发送一个软中断信号,下半部就从内存中找到网络数据,再按照网络协议栈,对数据进行逐层解析和处理,直到把它送给应用程序。
??

查看软中断和内核线程

??proc 文件系统,是一种内核空间和用户空间进行通信的机制,可以用来查看内核的数据结构,或者用来动态修改内核的配置。
??TASKLET 是最常用的软中断实现机制,每个 TASKLET 只运行一次就会结束 ,并且只在调用它的函数所在的 CPU 上运行。

$ cat /proc/softirqs  // 提供了软中断的运行情况:类型 + 中断次数
                    CPU0       CPU1
          HI:          2          0
       TIMER:      13086      12592
      NET_TX:          2         29
      NET_RX:        110       1803
       BLOCK:       8584       7866
    IRQ_POLL:          0          0
     TASKLET:         24         59
       SCHED:      10279      10218
     HRTIMER:          0          0
         RCU:      14262      13818

$ cat /proc/interrupts  // 提供了硬中断的运行情况
           CPU0       CPU1
  0:         35          0   IO-APIC   2-edge      timer
  1:         11        189   IO-APIC   1-edge      i8042

$ ps aux | grep softirq  // 查看软中断内核线程
root         6  0.0  0.0      0     0 ?        S    22:59   0:00 [ksoftirqd/0]
root        16  0.0  0.0      0     0 ?        S    22:59   0:00 [ksoftirqd/1]

??
??

案例调试方法:

??sar 是一个系统活动报告工具,既可以实时查看系统的当前活动,又可以配置保存和报告历史统计数据。
??hping3 是一个可以构造 TCP/IP 协议数据包的工具,可以对系统进行安全审计、防火墙测试等。

# -S 参数表示设置 TCP 协议的 SYN(同步序列号),-p 表示目的端口为 80
# -i u100 表示每隔 100 微秒发送一个网络帧
# 注:如果你在实践过程中现象不明显,可以尝试把 100 调小,比如调成 10 甚至 1
$ hping3 -S -p 80 -i u100 192.168.0.30

??tcpdump 是一个常用的网络抓包工具,常用来分析各种网络问题。
??Step 1:通过 top 查看软中断使用情况:

$ top # 运行后按数字 1 切换到显示所有 CPU
top - 10:50:58 up 1 days, 22:10,  1 user,  load average: 0.00, 0.00, 0.00
Tasks: 122 total,   1 running,  71 sleeping,   0 stopped,   0 zombie
%Cpu0  :  0.0 us,  0.0 sy,  0.0 ni, 96.7 id,  0.0 wa,  0.0 hi,  3.3 si,  0.0 st
%Cpu1  :  0.0 us,  0.0 sy,  0.0 ni, 95.6 id,  0.0 wa,  0.0 hi,  4.4 si,  0.0 st
...

PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
7 root      20   0       0      0      0 S   0.3  0.0   0:01.64 ksoftirqd/0
16 root      20   0       0      0      0 S   0.3  0.0   0:01.97 ksoftirqd/1

??Step 2:查看 /proc/softirqs 变化速率,使用 watch 可以看到变化,明确变化最大的软中断类型:TIMER(定时中断)、NET_RX(网络接收)、SCHED(内核调度)、RCU(RCU 锁)等

$ watch -d cat /proc/softirqs
CPU0       CPU1
HI:          0          0
TIMER:    1083906    2368646
NET_TX:         53          9
NET_RX:    1550643    1916776
BLOCK:          0          0
IRQ_POLL:          0          0
TASKLET:     333637       3930
SCHED:     963675    2293171
HRTIMER:          0          0
RCU:    1542111    1590625

??Step 3:通过 sar 查看系统具体情况:

$ sar -n DEV 1  # -n DEV 表示显示网络收发的报告,间隔 1 秒输出一组数据
15:03:46        IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s   %ifutil
15:03:47         eth0  12607.00   6304.00    664.86    358.11      0.00      0.00      0.00      0.01
15:03:47      docker0   6302.00  12604.00    270.79    664.66      0.00      0.00      0.00      0.00
15:03:47           lo      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
15:03:47    veth9f6bbcd   6302.00  12604.00    356.95    664.66      0.00      0.00      0.00      0.05
// 第一列:表示报告的时间
// 第二列:IFACE 表示网卡
// 第三、四列:rxpck/s 和 txpck/s 分别表示每秒接收、发送的网络帧数,也就是 PPS。
// 第五、六列:rxkB/s 和 txkB/s 分别表示每秒接收、发送的千字节数,也就是 BPS。
// 664 * 1024 / 12607 = 54 字节,小包数据!!!

??Step 4:针对上述网络小包问题,通过 tcpdump 查看具体网络和端口的问题:

# -i eth0 只抓取 eth0 网卡,-n 不解析协议名和主机名
# tcp port 80 表示只抓取 tcp 协议并且端口号为 80 的网络帧
$ tcpdump -i eth0 -n tcp port 80
15:11:32.678966 IP 192.168.0.2.18238 > 192.168.0.30.80: Flags [S], seq 458303614, win 512, length 0
...

??
??
??
??
??

原文地址:https://www.cnblogs.com/qccz123456/p/11385741.html

时间: 2024-11-05 16:41:32

Linux性能优化从入门到实战:05 CPU篇:硬中断、软中断的相关文章

Linux性能优化从入门到实战:01 Linux性能优化学习路线

??我通过阅读各种相关书籍,从操作系统原理.到 Linux内核,再到硬件驱动程序等等. ??把观察到的性能问题跟系统原理关联起来,特别是把系统从应用程序.库函数.系统调用.再到内核和硬件等不同的层级贯穿起来. ??性能优化是个系统工程,总是牵一发而动全身,它涉及了从程序设计.编程语言,再到系统.存储.网络等各种底层基础设施的方方面面.每一个组件都有可能出问题,而且很有可能多个组件同时出问题. ??讲解 Linux 性能的基本指标.工具,以及相应的观测.分析和调优方法.包括 CPU 性能.磁盘 I

Linux性能优化从入门到实战:04 CPU篇:CPU使用率

??CPU使用率是单位时间内CPU使用情况的统计,以百分比方式展示. $ top top - 11:46:45 up 7 days, 11:52, 1 user, load average: 0.00, 0.01, 0.00 Tasks: 198 total, 1 running, 197 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.2 us, 0.2 sy, 0.0 ni, 99.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st K

Linux性能优化从入门到实战:07 CPU篇:CPU性能优化方法

性能优化方法论 ??动手优化性能之前,需要明确以下三个问题: ??(1)如何评估性能优化的效果? 确定性能的量化指标.测试优化前的性能指标.测试优化后的性能指标. ??量化指标的选择.至少要从应用程序和系统资源这两个维度,分别选择不同的指标:1)应用程序的维度,我们可以用吞吐量和请求延迟来评估应用程序的性能.2)系统资源的维度,我们可以用 CPU 使用率来评估系统的 CPU 使用情况. ??行性能测试注意点:1)避免性能测试工具干扰应用程序的性能:2)避免外部环境的变化影响性能指标的评估. ??

Linux性能优化从入门到实战:03 CPU篇:CPU上下文切换

??linux操作系统是将CPU轮流分配给任务,分时执行的.而每次执行任务时,CPU需要知道CPU寄存器(CPU内置的内存)和程序计数器PC(CPU正在执行指令和下一条指令的位置)值,这些值是CPU执行任务所依赖的环境,也就是CPU上下文. ??CPU上下文切换,就是把前一个任务的CPU上下文(CPU寄存器和程序计数器)保存起来,然后加载入新任务的上下文到CPU寄存器和程序计数器中,最后跳转到程序计数器所指的位置,运行新任务. ??保存下来的上下文会在系统内核中,并在任务重新调度执行时再次加载进

Linux性能优化从入门到实战:06 CPU篇:快速定位CPU瓶颈

CPU性能指标 ?? ??(1)CPU使用率:1) 用户态CPU使用率(包括用户态 user 和低优先级用户态 nice).2) 系统CPU使用率.3) 等待 I/O 的CPU使用率.4) 软中断和硬中断的CPU使用率.5) 虚拟机占用的CPU使用率. ??(2)平均负载 Load Average:过去 1 分钟.过去 5 分钟和过去 15 分钟的平均负载 ??(3)进程上下文切换:1) 无法获取资源而导致的自愿上下文切换:2) 被系统强制调度导致的非自愿上下文切换. ??(4)CPU缓存命中率

Linux性能优化从入门到实战:02 CPU篇:平均负载

每次发现系统变慢时,我们通常做的第一件事,就是执行 top 或 uptime 命令: $ uptime 22:22:17 up 2 days, 20:14, 1 user, load average: 0.63, 0.83, 0.88 // 22:22:17 当前时间 up 2 days, 20:14 系统运行时间 1 user 正在登录用户数 // load average 过去 1 分钟.5 分钟.15 分钟的平均负载 ??平均负载是指单位时间内,系统处于可运行状态和不可中断状态的平均进程数

Linux性能优化从入门到实战:16 文件系统篇:磁盘 I/O 指标/工具总结、问题定位和调优

磁盘 I/O 性能指标 文件系统和磁盘 I/O 指标对应的工具 文件系统和磁盘 I/O 工具对应的指标 磁盘 I/O 问题定位分析思路 原文地址:https://www.cnblogs.com/qccz123456/p/11286833.html

Linux性能优化实战

你是否也曾跟我一样,看了很多书.学了很多 Linux 性能工具,但在面对 Linux 性能问题时,还是束手无策?实际上,性能分析和优化始终是大多数软件工程师的一个痛点.但是,面对难题,我们真的就无解了吗? 固然,性能问题的复杂性增加了学习难度,但这并不能成为我们进阶路上的“拦路虎”.在我看来,大多数人对性能问题“投降”,原因可能只有两个. 一个是你没找到有效的方法学原理,一听到“系统”.“底层”这些词就发怵,觉得东西太难自己一定学不会,自然也就无法深入学下去,从而不能建立起性能的全局观. 再一个

如何学习Linux性能优化?

如何学习Linux性能优化? 你是否也曾跟我一样,看了很多书.学了很多 Linux 性能工具,但在面对 Linux 性能问题时,还是束手无策?实际上,性能分析和优化始终是大多数软件工程师的一个痛点.但是,面对难题,我们真的就无解了吗? 固然,性能问题的复杂性增加了学习难度,但这并不能成为我们进阶路上的"拦路虎".在我看来,大多数人对性能问题"投降",原因可能只有两个. 一个是你没找到有效的方法学原理,一听到"系统"."底层"这