我们正在测试 Linux 服务器作为 VPN 路由器。
我们有一个相当好的服务器，我们现在遇到的中断约为 170k，但我们期望更多。 CPU使用率还可以。如何知道它们何时过多？当服务器不再能够处理它们时，CPU 负载是否会增加？
答案1
在/proc/interrupts等等中，中断被表示为计数器，即“自上次重新引导以来服务的〜170k中断”。在不知道系统已经启动并运行了多长时间的情况下，这样的计数器几乎完全没有意义。重要的是每单位时间的中断数量，或者中断率。
在 VPN 路由器上，中断主要由 NIC 产生，表明其输入缓冲区（或例如，对于更高级的服务器级 NIC，特定流的传入数据包的当前 DMA 目标）已满。如果 VPN 路由器无法及时处理所有中断，您可能会开始看到通过 VPN 的连接出现数据包丢失，或者实际 VPN 隧道可能出现故障并重新连接。
一个非常简单的 NIC 可能只有一个用于接收 X 个数据包的输入缓冲区，并在缓冲区接近满时生成一个中断，从而导致每个接收到的 (Xn) 个数据包产生一个中断。更先进的 NIC 可能能够自行进行 DMA 传输，因此处理器基本上可以告诉 NIC“这里有一块内存供您使用；将所有传入数据包（对于特定源地址/协议/端口组合）放入在那里，不要打扰我，直到内存块已满或传输似乎出现问题”，从而导致每个传输数据单元的中断少得多。因此，您使用的 NIC 的确切类型可能会对给定 VPN 流量工作负载生成的中断数量产生很大影响。
如果处理器不能及时处理中断，则可能会导致传入数据包丢失的情况，因为网卡没有地方存储它们。当单位时间的中断数量越来越多时，您应该看到 CPU 时间使用的百分比系统相应增加。
当中断率变得太大时，您实际上可能会看到减少CPU 负载，因为当入站数据包丢失时，除了等待另一端重新传输丢失的数据包之外，可能没有什么可做的。
根据您选择的具体 VPN 实现，“CPU 平均负载”值可能是也可能不是系统工作强度的有用指标，因为大部分与 VPN 相关的处理可能发生在内核内部。