1.平均负载案例分析
预先安装 stress 和 sysstat 包。(yum install -y stress , yum install -y sysstat)
stress 是一个 Linux 系统压力测试工具，这里我们用作异常进程模拟平均负载升高的场景。
sysstat 包含了常用的 Linux 性能工具，用来监控和分析系统的性能。我们的案例会用到这个包的两个命令 mpststat 和 pidstat。
- mpstat 是一个常用的多核 CPU 性能分析工具，用来实时查看每个 CPU 的性能指标，以及所有 CPU 的平均指标。
- pidstat 是一个常用的进程性能分析工具，用来实时查看进程的 CPU、内存、I/O 以及上下文切换等性能指标。
场景一：CPU 密集型进程
我们在第一个终端运行 stress 命令，模拟一个 CPU 使用率 100% 的场景：
|
|
接着，在第二个终端运行 uptime 查看平均负载的变化情况:
|
|
在第三个终端运行 mpstat 查看 CPU 使用率的变化情况：
|
|
分析：从终端二中可以看到，1 分钟的平均负载会慢慢增加到 0.99，而从终端三中还可以看到，正好有一个 CPU 的使用率为 100%，但它的 iowait 只有 0。这说明，平均负载的升高正是由于 CPU 使用率为 100% 。
那么，到底是哪个进程导致了 CPU 使用率为 100% 呢？可以使用 pidstat 来查询：
|
|
从这里可以明显看到，stress 进程的 CPU 使用率为100%。
场景二：I/O密集型进程
首先还是运行 stress 命令，但这次模拟 I/O压力，即不停地执行 sync：
|
|
还是在第二个终端运行 uptime 查看平均负载的变化情况：
|
|
然后，第三个终端运行 htop 查看 CPU 使用率的变化情况：
比如cpu密集型的应用，它的负载颜色是绿色偏高，iowait的操作，它的负载颜色是红色偏高等等,此案例的查看结果是红色偏高，正是iowait的操作导致的。根据这些指标再用htop的sort就很容易定位到有问题的进程。按上下键选择进程之后，按s,按s:用strace追踪进程的系统调用。
场景三：大量进程的场景
当系统中运行进程超出 CPU 运行能力时，就会出现等待 CPU 的进程。
我们还是使用 stress，但这次模拟的是 8 个进程：
|
|
由于系统只有 4个 CPU，明显比 8 个进程要少得多，因而，系统的 CPU 处于严重过载状态，平均负载高达 7.74.
|
|
在第三个终端中，输入htop,查看CPU使用情况，可以看出绿色显示4个CPU已经使用完，出现了CPU过载。
所以，在理解平均负载时，也要注意：
- 平均负载高有可能是 CPU 密集型进程导致的；
- 平均负载高并不一定代表 CPU 使用率高，还有可能是 I/O更繁忙了；
- 当发现负载高的时候，你可以使用 mpstat、pidstat，htop等工具，辅助分析负载的来源。
场景二和场景三没有使用pidstat查看，是因为CentOS默认的sysstat稍微有点老，不显示%wait的问题，所以用的htop查看的。
2.CPU 上下文切换案例
2.1怎么查看系统的上下文切换情况
vmstat 是一个常用的系统性能分析工具，主要用来分析系统的内存使用情况，也常用来分析 CPU 上下文切换和中断的次数。
|
|
- cs（context switch）是每秒上下文切换的次数。
- in（interrupt）则是每秒中断的次数。
- r（Running or Runnable）是就绪队列的长度，也就是正在运行和等待 CPU 的进程数。
- b（Blocked）则是处于不可中断睡眠状态的进程数。
2.2查看每个进程上下文切换的情况
|
|
- cswch ，表示每秒自愿上下文切换的次数。
- nvcswch ，表示每秒非自愿上下文切换的次数。
- 所谓自愿上下文切换，是指进程无法获取所需资源，导致的上下文切换。比如说， I/O、内存等系统资源不足时，就会发生自愿上下文切换。
- 而非自愿上下文切换，则是指进程由于时间片已到等原因，被系统强制调度，进而发生的上下文切换。比如说，大量进程都在争抢 CPU 时，就容易发生非自愿上下文切换。
2.3 案例实操
安装sysbench(yum install -y sysbench)
在第一个终端里运行 sysbench ，模拟系统多线程调度的瓶颈：
|
|
接着，在第二个终端运行 vmstat ，观察上下文切换情况。
|
|
- cs 列的上下文切换次数已经到了232万，同时，观查其他指标：
- r列：就绪队列到了7，远远超过了CPU的个数4，所以肯定会有CPU竞争。
- us（user）列和sy(system)列：这两列的CPU使用加起来到了90%，其中sy列的使用率到了71%，说明CPU主要被内核占用。
- in列：中断次数上升了2万多，说明中断也是潜在的问题。
综合这几个指标，我们可以知道，系统的就绪队列过长，也就是正在运行和等待 CPU 的进程数过多，导致了大量的上下文切换，而上下文切换又导致了系统 CPU 的占用率升高。
分析是什么进程导致：
pidstat -wt参数表示输出线程的上下文切换指标:
|
|
看来，上下文切换罪魁祸首，还是过多的 sysbench 线程。
分析中断问题的导致：
既然是中断，它只发生在内核态，而
pidstat 只是一个进程的性能分析工具，并不提供任何关于中断的详细信息。没错，那就是从 /proc/interrupts
这个只读文件中读取。/proc 实际上是 Linux 的一个虚拟文件系统，用于内核空间与用户空间之间的通信。/proc/interrupts
就是这种通信机制的一部分，提供了一个只读的中断使用情况。
|
|
观察一段时间，你可以发现，变化速度最快的是重调度中断（RES），这个中断类型表示，唤醒空闲状态的
CPU 来调度新的任务运行。这是多处理器系统（SMP）中，调度器用来分散任务到不同CPU
的机制，通常也被称为处理器间中断（Inter-Processor Interrupts，IPI）。
如果最开始时，我们只用了 pidstat 观测，这些很严重的上下文切换线程，压根儿就发现不了了。
这个数值其实取决于系统本身的
CPU
性能。在我看来，如果系统的上下文切换次数比较稳定，那么从数百到一万以内，都应该算是正常的。但当上下文切换次数超过一万次，或者切换次数出现数量级的增长时，就很可能已经出现了性能问题。所以，这里的中断升高还是因为过多任务的调度问题，跟前面上下文切换次数的分析结果是一致的。
所以：
- 自愿上下文切换变多了，说明进程都在等待资源，有可能发生了 I/O 等其他问题；
- 非自愿上下文切换变多了，说明进程都在被强制调度，也就是都在争抢 CPU，说明 CPU 的确成了瓶颈；
- 中断次数变多了，说明 CPU 被中断处理程序占用，还需要通过查看 /proc/interrupts 文件来分析具体的中断类型。
3.CPU使用率的案例
3.1CPU 使用率很高，但为啥却找不到高 CPU 的应用？
当你发现系统的 CPU 使用率很高的时候，不一定能找到相对应的高 CPU 使用率的进程。
首先要观察CPU的使用情况：使用top命令：
如果在top命令和pidstat
命令中都查看不到使用CPU较高的进程，那么需要从 CPU 使用率不高但处于 Running 状态的进程入手，找出了可疑之处，最终通过 perf
record -g 和 perf report 进行排查。发现原来是短时进程在捣鬼。
改案例需要在虚拟机中进行。预先安装 docker、sysstat、perf、ab 等工具，如 apt install docker.io sysstat linux-tools-common apache2-utils
1.首先，我们在第一个终端，执行下面的命令运行 Nginx 和 PHP 应用：
|
|
2.然后，在第二个终端，使用 curl 访问 http://[VM1 的 IP]:10000，确认 Nginx 已正常启动。你应该可以看到 It works! 的响应。
|
|
3.接着，我们来测试一下这个 Nginx 服务的性能。在第二个终端运行下面的 ab 命令。要注意，与上次操作不同的是，这次我们需要并发 100 个请求测试 Nginx 性能，总共测试 1000 个请求。
|
|
从 ab 的输出结果我们可以看到，Nginx 能承受的每秒平均请求数，只有 87 多一点，是不是感觉它的性能有点差呀。那么，到底是哪里出了问题呢？我们再用 top 和 pidstat 来观察一下。
4.这次，我们在第二个终端，将测试的并发请求数改成 5，同时把请求时长设置为 10 分钟（-t 600）。这样，当你在第一个终端使用性能分析工具时， Nginx 的压力还是继续的。
继续在第二个终端运行 ab 命令：
|
|
5.然后，我们在第一个终端运行 top 命令，观察系统的 CPU 使用情况：
|
|
观察 top 输出的进程列表可以发现，CPU 使用率最高的进程也只不过才 2.7%，看起来并不高。
然而，再看系统 CPU 使用率（ %Cpu ）这一行，你会发现，系统的整体 CPU 使用率是比较高的：用户 CPU 使用率（us）已经到了 80%，系统 CPU 为 15.1%，而空闲 CPU （id）则只有 2.8%。
为什么用户 CPU 使用率这么高呢？我们再重新分析一下进程列表，看看有没有可疑进程：
docker-containerd 进程是用来运行容器的，2.7% 的 CPU 使用率看起来正常；
Nginx 和 php-fpm 是运行 Web 服务的，它们会占用一些 CPU 也不意外，并且 2% 的 CPU 使用率也不算高；
再往下看，后面的进程呢，只有 0.3% 的 CPU 使用率，看起来不太像会导致用户 CPU 使用率达到 80%。
那就奇怪了，明明用户
CPU 使用率都 80% 了，可我们挨个分析了一遍进程列表，还是找不到高 CPU 使用率的进程。看来 top
是不管用了，那还有其他工具可以查看进程 CPU 使用情况吗？不知道你记不记得我们的老朋友 pidstat，它可以用来分析进程的 CPU
使用情况。
6.接下来，我们还是在第一个终端，运行 pidstat 命令：
|
|
观察一会儿，你是不是发现，所有进程的 CPU 使用率也都不高啊，最高的 Docker 和 Nginx 也只有 4% 和 3%，即使所有进程的 CPU 使用率都加起来，也不过是 21%，离 80% 还差得远呢！
7.现在，我们回到第一个终端，重新运行 top 命令，并观察一会儿：
|
|
这次从头开始看 top 的每行输出，咦？Tasks 这一行看起来有点奇怪，就绪队列中居然有 6 个 Running 状态的进程（6 running），是不是有点多呢？
回想一下 ab 测试的参数，并发请求数是 5。再看进程列表里， php-fpm 的数量也是 5，再加上 Nginx，好像同时有 6 个进程也并不奇怪。但真的是这样吗？
再仔细看进程列表，这次主要看
Running（R） 状态的进程。你有没有发现， Nginx 和所有的 php-fpm 都处于 Sleep（S）状态，而真正处于
Running（R）状态的，却是几个 stress 进程。这几个 stress 进程就比较奇怪了，需要我们做进一步的分析。
8.我们还是使用 pidstat 来分析这几个进程，并且使用 -p 选项指定进程的 PID。首先，从上面 top 的结果中，找到这几个进程的 PID。比如，先随便找一个 24344，然后用 pidstat 命令看一下它的 CPU 使用情况：
|
|
9.奇怪，居然没有任何输出。在怀疑性能工具出问题前，最好还是先用其他工具交叉确认一下，。那用什么工具呢？ ps 应该是最简单易用的。我们在终端里运行下面的命令，看看 24344 进程的状态：
|
|
10.还是没有输出。现在终于发现问题，原来这个进程已经不存在了，所以 pidstat 就没有任何输出。既然进程都没了，那性能问题应该也跟着没了吧。我们再用 top 命令确认一下：
|
|
11.好像又错了。结果还跟原来一样，用户 CPU 使用率还是高达 80.9%，系统 CPU 接近 15%，而空闲 CPU 只有 2.8%，Running 状态的进程有 Nginx、stress 等。
可是，刚刚我们看到 stress 进程不存在了，怎么现在还在运行呢？再细看一下 top 的输出，原来，这次 stress 进程的 PID 跟前面不一样了，原来的 PID 24344 不见了，现在的是 6779。
进程的 PID 在变，这说明什么呢？在我看来，要么是这些进程在不停地重启，要么就是全新的进程，这无非也就两个原因：
- 第一个原因，进程在不停地崩溃重启，比如因为段错误、配置错误等等，这时，进程在退出后可能又被监控系统自动重启了。
- 第二个原因，这些进程都是短时进程，也就是在其他应用内部通过 exec 调用的外面命令。这些命令一般都只运行很短的时间就会结束，你很难用 top 这种间隔时间比较长的工具发现（上面的案例，我们碰巧发现了）。
至于 stress，我们前面提到过，它是一个常用的压力测试工具。它的 PID 在不断变化中，看起来像是被其他进程调用的短时进程。要想继续分析下去，还得找到它们的父进程。
12.要怎么查找一个进程的父进程呢？没错，用 pstree 就可以用树状形式显示所有进程之间的关系：
|
|
从这里可以看到，stress 是被 php-fpm 调用的子进程，并且进程数量不止一个（这里是 3 个）。找到父进程后，我们能进入 app 的内部分析了。
分析原因：
perf 工具，它可以用来分析 CPU 性能事件，用在这里就很合适。依旧在第一个终端中运行 perf record -g 命令 ，并等待一会儿（比如 15 秒）后按 Ctrl+C 退出。然后再运行 perf report 查看报告：
|
|
结束案例：
|
|
小结:
碰到常规问题无法解释的 CPU 使用率情况时，首先要想到有可能是短时应用导致的问题，比如有可能是下面这两种情况。
- 第一，应用里直接调用了其他二进制程序，这些程序通常运行时间比较短，通过 top 等工具也不容易发现。
- 第二，应用本身在不停地崩溃重启，而启动过程的资源初始化，很可会占用相当多的 CPU。
3.2 等待 I/O 的 CPU的使用（多进程 I/O 的案例）
进程状态：当 iowait 升高时，进程很可能因为得不到硬件的响应，而长时间处于不可中断状态。从 ps 或者 top 命令的输出中，你可以发现它们都处于 D 状态，也就是不可中断状态。
首先使用top命令。查看系统的各个指标：
问题一：iowait升高
问题二：僵尸进程不断增多
首先看问题一：iowait问题分析
首先、使用工具dstat 进程查看，它的好处是，可以同时查看 CPU 和 I/O 这两种资源的使用情况，便于对比分析。
|
|
从 dstat 的输出，我们可以看到，每当 iowait 升高（wai）时，磁盘的读请求（read）都会很大。这说明iowait 的升高跟磁盘的读请求有关，很可能就是磁盘读导致的。
到底是哪个进程在读磁盘呢？我们在top中可以看到有D状态的不可中断进程很可疑，我们来分析一下：
第二、使用pidstat分析D状态的进程：
|
|
kB_rd 表示每秒读的 KB 数， kB_wr 表示每秒写的 KB 数，iodelay 表示 I/O 的延迟（单位是时钟周期）。它们都是 0，那就表示此时没有任何的读写，说明问题不是 116712进程导致的。
第三、使用pidstat 去掉-p参数，查看所有进程的IO情况：
|
|
观察一会儿可以发现，的确是 app 进程在进行磁盘读，并且每秒读的数据有 32 MB，看来就是 app 的问题。
第四、app 进程到底在执行啥 I/O 操作呢？
- strace 正是最常用的跟踪进程系统调用的工具。
|
|
结果可以看到没有权限。使用ps查看为啥没有权限？
|
|
可以看到该进程已经变成了僵尸进程，所以没有权限查看。
- 使用perf record -g 工具进行分析：
|
|
- 然后使用perf report -g 查看：
这个图里的 swapper 是内核中的调度进程，可以先忽略。
app
的确在通过系统调用 sys_read() 读取数据。并且从 new_sync_read 和 blkdev_direct_IO
能看出，进程正在对磁盘进行直接读，也就是绕过系统缓存，每个读请求都会从磁盘直接读，这就可以解释我们观察到的 iowait 升高了。
小结：
- 碰到 iowait 升高时，需要先用 dstat、pidstat 等工具，确认是不是磁盘 I/O 的问题，然后再找是哪些进程导致了 I/O。
- 等待 I/O 的进程一般是不可中断状态，所以用 ps 命令找到的 D 状态（即不可中断状态）的进程，多为可疑进程。但这个案例中，在 I/O 操作后，进程又变成了僵尸进程，所以不能用strace 直接分析这个进程的系统调用。
- 这种情况下，我们用了 perf 工具来分析系统的 CPU 时钟事件，最终发现是直接 I/O 导致的问题。
4.系统的软中断CPU使用率升高，该怎么办？
预先安装 docker、sysstat、sar 、hping3、tcpdump 等工具，比如 apt-get install docker.io sysstat hping3 tcpdump。
- sar 是一个系统活动报告工具，既可以实时查看系统的当前活动，又可以配置保存和报告历史统计数据。
- hping3 是一个可以构造 TCP/IP 协议数据包的工具，可以对系统进行安全审计、防火墙测试等。
- tcpdump 是一个常用的网络抓包工具，常用来分析各种网络问题。
本次案例用到两台虚拟机。你可以看到，其中一台虚拟机运行 Nginx ，用来模拟待分析的 Web 服务器；而另一台当作 Web 服务器的客户端，用来给 Nginx 增加压力请求。使用两台虚拟机的目的，是为了相互隔离，避免“交叉感染”。
同以前的案例一样，下面的所有命令都默认以 root 用户运行，如果你是用普通用户身份登陆系统，请运行 sudo su root 命令切换到 root 用户。
操作和分析
安装完成后，我们先在第一个虚拟机，执行下面的命令运行案例，也就是一个最基本的 Nginx 应用：
|
|
然后，在第二个虚拟机，使用 curl 访问 Nginx 监听的端口，确认 Nginx 正常启动。假设172.16.109.245 是 Nginx 所在虚拟机的 IP 地址，运行 curl 命令后你应该会看到下面这个输出界面：
|
|
接着，还是在第二个虚拟机，我们运行 hping3 命令，来模拟 Nginx 的客户端请求：
|
|
现在我们再回到第一个虚拟机，你应该发现了异常。是不是感觉系统响应明显变慢了，即便只是在终端中敲几个回车，都得很久才能得到响应？这个时候应该怎么办呢？
虽然在运行 hping3 命令时，这是一个 SYN FLOOD 攻击，你肯定也会想到从网络方面入手，来分析这个问题。不过，在实际的生产环境中，没人直接告诉你原因。所以希望你把 hping3 模拟 SYN FLOOD 这个操作暂时忘掉，然后重新从观察到的问题开始，分析系统的资源使用情况，逐步找出问题的根源。
那么，该从什么地方入手呢？刚才我们发现，简单的 SHELL 命令都明显变慢了，先看看系统的整体资源使用情况应该是个不错的注意，比如执行下 top 看看是不是出现了 CPU 的瓶颈。我们在第一个终端运行 top 命令，看一下系统整体的资源使用情况。
|
|
我们从第一行开始，逐个看一下：
- 平均负载在1左右，就绪队列里面有2个进程（2 running）。
- 每个 CPU 的使用率都挺低，si: 处理软件中断的CPU时间是49.5%
- 再看进程列表，CPU 使用率最高的进程也只有 5%，还是不高呀。
根据上一期的内容，既然软中断可能有问题，那你先要知道，究竟是哪类软中断的问题。停下来想想，上一节我们用了什么方法，来判断软中断类型呢？没错，还是 proc 文件系统。观察 /proc/softirqs 文件的内容，你就能知道各种软中断类型的次数。
不过，这里的各类软中断次数，又是什么时间段里的次数呢？它是系统运行以来的累积中断次数。所以我们直接查看文件内容，得到的只是累积中断次数，对这里的问题并没有直接参考意义。因为，这些中断次数的变化速率才是我们需要关注的。
那什么工具可以观察命令输出的变化情况呢？我想你应该想起来了，在前面案例中用过的 watch 命令，就可以定期运行一个命令来查看输出；如果再加上 -d 参数，还可以高亮出变化的部分，从高亮部分我们就可以直观看出，哪些内容变化得更快。
比如，还是在第一个虚拟机，我们运行下面的命令：
|
|
通过 /proc/softirqs 文件内容的变化情况，你可以发现， TIMER（定时中断）、NET_RX（网络接收）、SCHED（内核调度）、RCU（RCU 锁）等这几个软中断都在不停变化。
其中，NET_RX，也就是网络数据包接收软中断的变化速率最快。而其他几种类型的软中断，是保证 Linux 调度、时钟和临界区保护这些正常工作所必需的，所以它们有一定的变化倒是正常的。
那么接下来，我们就从网络接收的软中断着手，继续分析。既然是网络接收的软中断，第一步应该就是观察系统的网络接收情况。这里你可能想起了很多网络工具，不过，我推荐今天的主人公工具 sar 。
sar 可以用来查看系统的网络收发情况，还有一个好处是，不仅可以观察网络收发的吞吐量（BPS，每秒收发的字节数），还可以观察网络收发的 PPS，即每秒收发的网络帧数。
我们在第一个终端中运行 sar 命令，并添加 -n DEV 参数显示网络收发的报告：
|
|
对于 sar 的输出界面，我先来简单介绍一下，从左往右依次是：
- 第一列：表示报告的时间。
- 第二列：IFACE 表示网卡。
- 第三、四列：rxpck/s 和 txpck/s 分别表示每秒接收、发送的网络帧数，也就是 PPS。
- 第五、六列：rxkB/s 和 txkB/s 分别表示每秒接收、发送的千字节数，也就是 BPS。
- 后面的其他参数基本接近 0，显然跟今天的问题没有直接关系，你可以先忽略掉。
我们具体来看输出的内容，你可以发现：
对网卡ens33来说，每秒接收的网络帧数比较大，达到了 23260，而发送的网络帧数则比较小，只有 14758；每秒接收的千字节数只有 1362 KB，而发送的千字节数更小，只有 864 KB。
docker0 和veth7734be2的数据基本一致，只是发送和接收相反，发送的数据较大而接收的数据较小。这是 Linux 内部网桥转发导致的，你暂且不用深究，只要知道这是系统把 ens33 收到的包转发给 Nginx 服务即可。
既然怀疑是网络接收中断的问题，我们还是重点来看 ens33 ：接收的 PPS 比较大，达到 23260，而接收的 BPS 却很小，只有 1362 KB。直观来看网络帧应该都是比较小的，我们稍微计算一下，1362*1024/23260= 59 字节，说明平均每个网络帧只有 59 字节，这显然是很小的网络帧，也就是我们通常所说的小包问题。
那么，有没有办法知道这是一个什么样的网络帧，以及从哪里发过来的呢？
使用 tcpdump 抓取 ens33 上的包就可以了。我们事先已经知道， Nginx 监听在 80 端口，它所提供的 HTTP 服务是基于 TCP 协议的，所以我们可以指定 TCP 协议和 80 端口精确抓包。
接下来，我们在第一个终端中运行 tcpdump 命令，通过 -i ens33 选项指定网卡 ens33，并通过 tcp port 80 选项指定 TCP 协议的 80 端口：
|
|
从 tcpdump 的输出中，你可以发现172.16.109.170.58080
> 172.16.109.245.80，表示网络帧从 172.16.109.170 的 58080 端口发送到
172.16.109.245 的 80 端口，也就是从运行 hping3 机器的 58080 端口发送网络帧，目的为 Nginx 所在机器的
80 端口。
Flags [S] 则表示这是一个 SYN 包。
再加上前面用 sar 发现的， PPS 超过 23260 的现象，现在我们可以确认，这就是从 172.16.109.170 这个地址发送过来的 SYN FLOOD 攻击。
到这里，我们已经做了全套的性能诊断和分析。从系统的软中断使用率高这个现象出发，通过观察 /proc/softirqs 文件的变化情况，判断出软中断类型是网络接收中断；再通过 sar 和 tcpdump ，确认这是一个 SYN FLOOD 问题。
SYN FLOOD 问题最简单的解决方法，就是从交换机或者硬件防火墙中封掉来源 IP，这样 SYN FLOOD 网络帧就不会发送到服务器中。
案例结束后，也不要忘了收尾，记得停止最开始启动的 Nginx 服务以及 hping3 命令。
在第一个终端中，运行下面的命令就可以停止 Nginx 了：
|
|
然后到第二个终端中按下 Ctrl+C 就可以停止 hping3。
小结：
软中断 CPU 使用率（softirq）升高是一种很常见的性能问题。虽然软中断的类型很多，但实际生产中，我们遇到的性能瓶颈大多是网络收发类型的软中断，特别是网络接收的软中断。
在碰到这类问题时，你可以借用 sar、tcpdump 等工具，做进一步分析。
原文地址：https://www.cnblogs.com/summerxye/p/11114361.html