linux性能评估-cpu案例操作篇

标签：span   tar   机制   ati   虚拟机   ade   用户空间   火墙   ase   

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 等工具，做进一步分析。

linux性能评估-cpu案例操作篇

标签：span   tar   机制   ati   虚拟机   ade   用户空间   火墙   ase   

原文地址：https://www.cnblogs.com/summerxye/p/11114361.html