一、实验环境
二、实验案例分析
安装完成后,我们先在第一个终端,执行下面的命令运行案例,也就是一个最基本的 Nginx 应用:
运行 Nginx 服务并对外开放 80 端口
# docker run -itd --name=nginx -p 80:80 nginx
然后,在第二个终端,使用 curl 访问 Nginx 监听的端口,确认 Nginx 正常启动。
假设 192.168.0.30 是 Nginx 所在虚拟机的 IP 地址,运行 curl 命令后,你应该会看到下面这个输出界面:
# curl http://192.168.0.30/
接着,还是在第二个终端中,运行 hping3 命令,模拟 Nginx 的客户端请求:
# hping3 -S -p 80 -i u10 192.168.0.30
现在,我们再回到第一个终端,你应该就会发现异常——系统的响应明显变慢了。
我们不妨执行 top,观察一下系统和进程的 CPU 使用情况:
从 top 的输出中,你可以看到,两个 CPU 的软中断使用率都超过了 30%;而 CPU 使用率最高的进程,正好是软中断内核线程 ksoftirqd/0 和 ksoftirqd/1。
虽然,我们已经知道了 ksoftirqd 的基本功能,可以猜测是因为大量网络收发,引起了 CPU 使用率升高;但它到底在执行什么逻辑,我们却并不知道。
对于普通进程,我们要观察其行为有很多方法,比如 strace、pstack、lsof 等等。但这些工具并不适合内核线程,比如,如果你用 pstack ,或者通过 /proc/pid/stack 查看 ksoftirqd/0(进程号为 9)的调用栈时,分别可以得到以下输出:
那还有没有其他方法,来观察内核线程 ksoftirqd 的行为呢?
既然是内核线程,自然应该用到内核中提供的机制。回顾一下我们