irqbalance 是什么?项目主页上有以下描述:
Irqbalance is a daemon to help balance the cpu load generated by interrupts across all of a systems cpus.
它避免了单 cpu 负载过重情况的出现。用法如下:
root@a7661ef9b2f8 test]# irqbalance -h
irqbalance: option requires an argument -- 'h'
irqbalance [--oneshot | -o] [--debug | -d] [--foreground | -f] [--hintpolicy= | -h [exact|subset|ignore]] [--banscript= | -b <script>]
[--powerthresh= | -p <off> | <n>] [--banirq= | -i <n>] [--policyscript= | -l <script>] [--pid= | -s <file>] [--deepestcache= | -c <n>]
# 查看当前运行情况
service irqbalance status
# 终止服务
service irqbalance stop
首先有一些前置知识需要说明,这涉及到 irqbalance cputree 的分层。
前置知识
中断
每个硬件设备都需要和 CPU 有某种形式的通信以便 CPU 及时知道发生了什么,这样 CPU 可能就会放下手中的事情去处理应急事件,硬件设备主动打扰 CPU 的现象就可称为硬件中断。就像正在一心一意的写代码时,突然钉钉“噔噔”地响起来,这时我们就知道有事情需要处理,这里的“噔噔”声就可以理解成一次中断。
CPU 和硬件沟通的方式中,还有一种叫做轮询(polling),就是让 CPU 定时对硬件状态进行查询然后做相应处理,这比较浪费 CPU,属于一种硬件被动的方式。相比下来,硬件主动的方式(中断)更有效一些。
那每个硬件设备都有中断,很简单啊,给它们分个唯一的号码,也就是 irq 号,在 /proc/interrupts
文件中的第一列可以看到所有的irq。
只有 kernel 2.4 以后的版本才支持的把不同的硬件中断请求(IRQs)分配到特定的 CPU 上的绑定技术被称为 SMP IRQ Affinity,这个后面还会详细说。
NUMA架构
简要介绍一下 NUMA 架构。
NUMA 架构出现前,CPU 频率一路欢脱越来越高,直至碰到物理极限的天花板,后转向核数越来越多的方向发展。
如果每个 core 的工作性质都是 share-nothing(类似于map-reduce的node节点的作业属性),那么也许就不会有NUMA。由于所有CPU Core都是通过共享一个北桥来读取内存,随着核数如何的发展, 北桥 在响应时间上的性能瓶颈越来越明显。于是,聪明的硬件设计师们,先到了把内存控制器(原本北桥中读取内存的部分)也做个拆分,平分到了每个die上。于是 NUMA 就出现了!
NUMA 架构中,内存访问有远近之分,只有当 CPU 访问自身直接 attach 内存对应的物理地址时,才会有较短的响应时间(Local Access)。而如果需要访问其他 CPU attach 的内存的数据时,就需要通过 inter-connect 通道访问,响应时间就相比之前变慢了