前阵子在7DGroup群里讨论了一个系统遇到的性能问题。在此记录一下,以备后查。


背景信息

技术架构图如下所示:

性能分析之进程过多导致的page faults_php

这是一个PHP应用,单个查询接口做基准场景的压力测试,调用链如下:

性能分析之进程过多导致的page faults_php_02


性能问题一


  • 问题现象

先看一下压力数据。

性能分析之进程过多导致的page faults_云服务_03

从TPS和RT图上,看到响应时间在不断地下降,TPS似乎也没有上升。


在这个问题中,我们要解决的是为啥TPS上不去、系统资源又用不完的问题。


  • 问题分析

因为这个系统架构非常简单,所以这里可以跳过 RESAR性能分析七步法 的拆分响应时间这一步。架构在上面也已经有了。

现在我们直接去到服务器上看系统资源的使用情况。 

性能分析之进程过多导致的page faults_数据_04

从图上看,CPU资源还没有完全用完,但TPS已经上不去了(即便TPS还能增加,也增加不了多少,毕竟只有23.5%的空闲CPU了)。si cpu 6.9%。

通常这种情况下,我们分析的时候,因为CPU的id还有23.5%,所以根据我的优化逻辑,应该是先把CPU消耗光,因为CPU没有消耗光的时候,通常是已经有了瓶颈,并且这样的瓶颈通常都和这几个词相关:队列、锁、池。

简单来说,就是路不够宽,所以CPU才用不上那么多。 


这里我们要查各种日志,因为当某个资源达到了上限时,通常都会给出异常日志。

在应用的服务器里,要查的日志通常就会包括两类:1. 应用日志;2. 系统日志。 

当用dmesg查看系统日志时,看到如下信息:


nf_conntrack: table full, dropping packet.

这个日志非常明显,nf_conntrack满了,我们把它加大就可以。

nf_conntrack(以前叫 ip_conntrack)是 Linux 中一个跟踪 TCP 连接条目的模块,它会用一个哈希表记录 TCP 的连接信息。当这个哈希表满了之后,就会报nf_conntrack: table full,dropping packet这样的错误。

有个参数来控制这个表的最大值就是net.netfilter.nf_conntrack_max。

这个问题,我在专栏中也有写过,原理也有解释过。


不过!这里是不是只有这个问题呢?还不止,在我们查看系统级的全局监控数据时,还看到如下信息:

性能分析之进程过多导致的page faults_ios_05

也就是服务器端的send_Q有值,提醒一下,这个值并不是只看一次就可以,而是持续观察一段时间,长时间有值才是有问题。 

而这时查看应用的进程总共有64个。

性能分析之进程过多导致的page faults_数据_06

PHP是多线程单进程的管理模式。而现在又是发不出去数据,面对的又是压力机,所以,需要关心压力机和应用服务器之间的网络情况,先查一下有多少跳。

性能分析之进程过多导致的page faults_ios_07

看下来,似乎也不近。通常这种情况下,最快的验证方式就是把压力机放到和应用服务器在同一网段。

在性能分析的过程中,如果你对网络的控制权限和基础知识没有达到去操作被测路径上的每一个网络设备的时候,我劝你尽快绕过中间设备,因为在很多企业中,这个沟通都是非常耗时且经常会沟通不到重点。


  • 优化效果

在这里,我们把压力机换到内网服务器上之后,效果如下:

性能分析之进程过多导致的page faults_云服务_08


从数据上看,tps达到300左右,比之前高了,响应时间也稳定了(其实这里响应时间还是长,要分析下去,还是有发挥的空间的)。 

再来看一下服务器资源使用情况。

性能分析之进程过多导致的page faults_sed_09

再看下应用进程数。

性能分析之进程过多导致的page faults_数据_10

也就是说把压力机移到内网中,压力就可以立即上来了。这也充分说明了网络对TPS的影响。


性能问题二


  • 问题现象

这个问题和上一个问题并不是在同一个环境,但应用是同一个版本。

在这个环境中,硬件资源要少一些,应用是2C4G的云服务器。

性能分析之进程过多导致的page faults_sed_11

从TPS和RT曲线上来看,就知道是规律性的抖动。

我们现在要定位的就是为什么这么抖动的问题。


  • 问题分析


根据我提出的RESAR分析逻辑,先看全局监控,后做定向监控。


来看下有什么信息可以分析的,首先这位同学给出来的是云服务器自带的监控界面。

性能分析之进程过多导致的page faults_sed_12

注意:通常情况下,有很多做性能分析的时候,看到这个界面以为就是看到了有效的数据。不止是性能分析人员这样想,做运维的人也认为给了这些数据就够了。但实际上,这些数据远远不够分析。但现在的云平台几乎给的都是这些差不多的数据,所以,在云服务器上做分析,大部分时候都是需要我们执行命令去收集数据的。这也是现在使用云服务器的大弊端之一。 


由此可见,云服务器的监控界面,基本上不可做为全局监控数据来使用。


这时候怎么办呢?只有进到服务器里执行全局监控的命令。先来个top:


















top - 16:00:03 up 105 days, 20:14,  3 users,  load average: 178.80, 174.37, 121.59Tasks: 475 total, 164 running, 232 sleeping,   0 stopped,   9 zombie%Cpu0  : 71.2 us, 25.2 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  3.6 si,  0.0 st%Cpu1  : 73.0 us, 23.3 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  3.7 si,  0.0 stKiB Mem :  3881904 total,   143380 free,  2913448 used,   825076 buff/cacheKiB Swap:        0 total,        0 free,        0 used.   123224 avail Mem 
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 30 root 20 0 0 0 0 S 4.6 0.0 387:24.77 kswapd0 607 root 20 0 1201328 16732 1468 S 3.3 0.4 136:27.39 barad_agent 10519 ops 20 0 706456 8760 680 S 3.3 0.2 135:50.02 ftrace_udp_agen 1 root 20 0 190876 2664 1168 S 2.0 0.1 96:52.92 systemd 635 dbus 20 0 28140 2312 344 R 2.0 0.1 129:10.52 dbus-daemon 8544 root 20 0 775288 18612 8932 S 2.0 0.5 4:14.55 YDEdr 349 root 20 0 53604 3684 3304 S 1.7 0.1 58:35.04 systemd-journal 14345 ops 20 0 1278392 17644 9056 R 1.7 0.5 0:07.48 php-fpm 5631 ops 20 0 1278392 17684 9072 R 1.3 0.5 0:09.28 php-fpm

有人要说了,top又多了啥呢?其实你仔细看就知道:

  1. cpu 计数器是8个,并且每个都能看到值。
  2. 有load average。
  3. 内存有具体的数值。
  4. 可以看到process table。

这些够不够呢?这就要取决于是什么问题了,当top不能让我们进行下一步时,还要执行其他的全局监控命令。

由于在linux中并没有一个命令可以看到所有的系统性能计数器,所以只能执行多个命令来覆盖(vmstat/iostat/netstat等)。


先来分析一下,在上面的top数据中,有什么疑点呢:

  1. cpu已经被消耗光了,id 已经为0了,但us cpu只有70%左右。

  2. load average也非常高,在2C的服务器上达到了170多的队列长度,真是过分了。

  3. sy cpu达到了25%左右,这个也过分了。

  4. 从process table里来看,有一个kswapd0,这是管理页交换的。

而以上的这些有价值的信息,通过云服务器的监控界面是一个也看不到的。


通过以上几点重要的信息,下面我们相应地再查几组数据,然后再进行关联综合分析。


































































































































[ops@xxxxxx-null ~]$ sar -B 1Linux 3.10.0-514.21.1.el7.x86_64 (QC_GZ-172_24_19_171-null)   06/11/2021   _x86_64_  (2 CPU)
05:16:37 PM pgpgin/s pgpgout/s fault/s majflt/s pgfree/s pgscank/s pgscand/s pgsteal/s %vmeff05:16:38 PM 2428.00 112.00 11481.00 8.00 16976.00 0.00 0.00 0.00 0.0005:16:39 PM 23691.09 139.60 16352.48 0.99 28139.60 18412.87 0.00 17388.12 94.4305:16:40 PM 11172.00 0.00 12116.00 5.00 18185.00 0.00 0.00 0.00 0.0005:16:41 PM 4444.00 0.00 3368.00 3.00 12457.00 0.00 0.00 0.00 0.0005:16:42 PM 4.00 0.00 5399.00 1.00 13263.00 0.00 0.00 0.00 0.0005:16:43 PM 4.00 0.00 2674.00 1.00 14081.00 0.00 0.00 0.00 0.0005:16:44 PM 0.00 31.68 2530.69 0.00 13134.65 0.00 0.00 0.00 0.0005:16:45 PM 420.00 0.00 4992.00 4.00 14598.00 0.00 0.00 0.00 0.0005:16:46 PM 8.00 0.00 2582.00 2.00 12660.00 0.00 0.00 0.00 0.0005:16:47 PM 0.00 0.00 2520.00 0.00 13658.00 0.00 0.00 0.00 0.0005:16:48 PM 0.00 0.00 2770.30 0.00 13668.32 0.00 0.00 0.00 0.0005:16:49 PM 2200.00 0.00 2825.00 2.00 11906.00 0.00 0.00 0.00 0.0005:16:50 PM 8.00 316.00 5241.00 0.00 12759.00 0.00 0.00 0.00 0.0005:16:51 PM 0.00 0.00 2605.00 0.00 10551.00 0.00 0.00 0.00 0.0005:16:52 PM 0.00 0.00 5153.00 0.00 13309.00 0.00 0.00 0.00 0.0005:16:53 PM 0.00 0.00 6580.00 0.00 24864.00 0.00 0.00 0.00 0.0005:16:54 PM 16.00 12624.00 2838.00 0.00 12658.00 0.00 0.00 0.00 0.0005:16:55 PM 3.96 75.25 4837.62 0.00 14996.04 0.00 0.00 0.00 0.0005:16:56 PM 20.00 0.00 2799.00 1.00 12374.00 0.00 0.00 0.00 0.0005:16:57 PM 2596.00 0.00 5063.00 5.00 15248.00 0.00 0.00 0.00 0.0005:16:58 PM 7.92 0.00 2525.74 0.00 13568.32 0.00 0.00 0.00 0.0005:16:59 PM 0.00 0.00 2897.00 0.00 12689.00 0.00 0.00 0.00 0.0005:17:00 PM 52.00 0.00 5115.00 1.00 14965.00 0.00 0.00 0.00 0.0005:17:01 PM 3432.00 247.00 4049.00 2.00 13372.00 0.00 0.00 0.00 0.0005:17:02 PM 13680.00 108.00 24726.00 96.00 14860.00 0.00 0.00 0.00 0.0005:17:03 PM 38308.00 436.00 74812.00 273.00 59709.00 31661.00 0.00 30270.00 95.6105:17:04 PM 19668.00 4861.00 50836.00 217.00 50120.00 21439.00 3326.00 23184.00 93.6205:17:05 PM 29104.95 1172.28 34513.86 181.19 34986.14 21929.70 0.00 20190.10 92.0705:17:06 PM 56416.83 1906.93 49170.30 201.98 46266.34 22119.80 0.00 21058.42 95.2005:17:07 PM 132063.73 550.98 26121.57 359.80 54441.18 35367.65 2843.14 36667.65 95.9605:17:08 PM 140647.22 85.47 6047.46 475.79 53316.95 332737.53 673634.87 31309.44 3.1105:17:14 PM 147070.19 60.87 8724.22 465.53 71342.86 960378.88 2018672.36 36032.30 1.2105:17:14 PM 64550.00 0.00 143087.50 862.50 149162.50 0.00 0.00 0.00 0.0005:17:15 PM 92045.00 52.00 174568.00 690.00 48202.00 0.00 0.00 0.00 0.0005:17:16 PM 54492.00 108.00 122016.00 436.00 75954.00 0.00 0.00 0.00 0.0005:17:17 PM 3056.00 0.00 81783.00 49.00 24937.00 0.00 0.00 0.00 0.0005:17:18 PM 4516.00 4.00 74144.00 73.00 60364.00 0.00 0.00 0.00 0.0005:17:19 PM 2784.16 27.72 16536.63 1.98 18620.79 0.00 0.00 0.00 0.0005:17:20 PM 8944.00 0.00 15552.00 2.00 13285.00 0.00 0.00 0.00 0.0005:17:21 PM 3688.00 552.00 31403.00 11.00 19743.00 0.00 0.00 0.00 0.0005:17:22 PM 1805.94 0.00 17313.86 0.99 14853.47 0.00 0.00 0.00 0.0005:17:23 PM 3992.00 0.00 7831.00 0.00 18488.00 0.00 0.00 0.00 0.0005:17:24 PM 5972.00 0.00 10727.00 3.00 10108.00 0.00 0.00 0.00 0.0005:17:25 PM 10376.00 0.00 6539.00 19.00 14876.00 0.00 0.00 0.00 0.0005:17:26 PM 16920.00 144.00 6997.00 4.00 12119.00 0.00 0.00 0.00 0.00
[ops@xxxxxx-null ~]$ vmstat 1procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st218 10 0 145864 2952 756036 0 0 1323 93 0 1 7 2 89 2 0231 10 0 124852 2496 748252 0 0 81672 119 7689 6395 69 32 0 0 0224 12 0 110848 1356 723592 0 0 39582 507 8786 6771 72 28 0 0 095 71 0 88360 196 710604 0 0 816904 873 27306 27572 13 78 0 8 068 10 0 102900 7016 881700 0 0 88965 8 5425 6100 60 40 0 0 068 7 0 244032 8272 859476 0 0 59032 60 6473 6845 65 35 0 0 076 5 0 285132 8844 871252 0 0 13104 8 7963 7489 76 24 0 0 0112 1 0 303520 9200 873980 0 0 2388 4 7567 6675 76 24 0 0 0129 1 0 230600 9692 883212 0 0 9444 380 8103 6854 69 31 0 0 0145 0 0 242124 9732 890496 0 0 6204 4 9292 8441 78 22 0 0 0166 0 0 213028 9752 897756 0 0 6544 0 8881 7795 79 21 0 0 0162 1 0 197468 10044 900888 0 0 2516 0 9290 8153 80 21 0 0 0191 1 0 206824 11168 911960 0 0 13180 0 10097 9118 78 22 0 0 0126 1 0 203336 11180 913396 0 0 1440 280 10015 8836 82 18 0 0 0176 0 0 188376 11180 917688 0 0 4092 0 10803 9574 82 18 0 0 0191 1 0 174668 11596 923228 0 0 5812 0 9830 9114 84 17 0 0 0203 2 0 155228 11636 931476 0 0 8832 0 10648 9316 81 19 0 0 0127 3 0 143336 11636 940520 0 0 9089 0 11578 9979 79 21 0 0 0146 1 0 112528 11776 959636 0 0 19300 0 9510 8703 83 17 0 0 0170 1 0 120620 10740 952520 0 0 15532 96 9831 8649 82 18 0 0 0183 2 0 120652 10276 944988 0 0 15644 157 10171 9378 80 20 0 0 0194 2 0 146280 8820 918372 0 0 17388 457 9458 8180 83 17 0 0 0200 3 0 91428 7600 931980 0 0 29656 178 9205 8073 82 18 0 0 0109 2 0 167932 5804 866800 0 0 8658 19728 10093 8987 77 23 0 0 0
[ops@xxxxxx-null ~]$ iostat -x -d 1Linux 3.10.0-514.21.1.el7.x86_64 (QC_GZ-172_24_19_171-null) 06/11/2021 _x86_64_ (2 CPU)
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %utilvda 0.32 6.71 52.50 9.48 2018.28 98.98 68.32 0.07 1.18 0.31 6.00 0.41 2.51vdb 0.01 0.42 31.45 2.77 618.48 85.87 41.16 0.08 2.22 1.56 9.69 0.69 2.37scd0 0.00 0.00 0.00 0.00 0.00 0.00 10.18 0.00 0.79 0.79 0.00 0.79 0.00
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %utilvda 18.81 0.00 2047.52 409.90 122364.36 4071.29 102.90 11.08 4.61 3.78 8.76 0.32 77.82vdb 0.00 0.00 256.44 6.93 4556.93 27.72 34.82 0.29 1.10 1.11 0.86 0.58 15.35scd0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %utilvda 7.00 0.00 917.00 0.00 51412.00 0.00 112.13 2.67 2.91 2.91 0.00 0.38 35.10vdb 0.00 0.00 288.00 3.00 6588.00 35.50 45.52 0.26 0.90 0.90 1.00 0.59 17.30scd0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %utilvda 3.00 0.00 169.00 0.00 5724.00 0.00 67.74 0.33 1.96 1.96 0.00 0.37 6.30vdb 0.00 0.00 127.00 1.00 3120.00 4.00 48.81 0.15 1.20 1.20 1.00 0.98 12.60scd0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %utilvda 0.00 0.00 242.00 0.00 1920.00 0.00 15.87 0.45 1.84 1.84 0.00 0.21 5.20vdb 0.00 0.00 14.00 1.00 376.50 4.00 50.73 0.01 0.53 0.50 1.00 0.53 0.80scd0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %utilvda 2.00 67.00 547.00 8.00 11348.00 300.00 41.97 1.01 1.81 1.78 4.25 0.33 18.10vdb 0.00 0.00 12.00 1.00 3980.00 4.00 612.92 0.08 6.31 6.33 6.00 1.38 1.80scd0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %utilvda 0.00 0.00 19.80 129.70 831.68 772.28 21.46 0.32 2.15 2.15 2.15 0.14 2.08vdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00scd0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %utilvda 1.00 0.00 172.00 0.00 5812.00 0.00 67.58 0.30 1.74 1.74 0.00 0.29 5.00vdb 0.00 0.00 6.00 0.00 24.00 0.00 8.00 0.00 0.33 0.33 0.00 0.33 0.20scd0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

[ops@xxxxxx-null ~]$ free -h total used free shared buff/cache availableMem: 3.7G 2.7G 190M 491M 871M 231MSwap: 0B 0B 0B
[ops@xxxxxx-null ~]$ ps -ef |grep php |wc -l229

这里查的几个数据是:sar -B/vmstat/iostat/free/进程数。

我先来说一下为什么要看这几组数据。

  1. 看sar -B是因为在top中看到了kswapd0,通过sar -B中的page faults,我要判断有多少的页交换的存在。

  2. 看vmstat是为了确定哪个队列比较长。

  3. 看iostat是为了知道是否有异常的读,这里我只为了看异常的读,而不是为了看写。

  4. 看free是为了看内存使用情况,关键是有多少可用的。

  5. 看进程数是为了计算进程是否合理。


现在就得来综合分析一下了。

  • 从sar -B中看到faults较大的时候是十几万、maj-faults 几百,这显然是有大量的页交换了。既然有页交换,那基本上可以说明内存使用上有问题,有可能是不足、也有可能是其他问题,这里我们不做判断。接着往下。

  • vmstat中看到Swap是关着的,那显然faults和swap大小无关,因为根本就没开。cpu队列显然是过长的,达到100多,而这个机器只有2C,那必然是应用的工作线程过多了,至于多少工作线程才叫不多,呆会再算。

  • iostat中计算得到,一次读大概是14个block,显然是顺序读居多,比较合理,在IO上应该没有问题。

  • 从free上来看只有200多M的可用内存,同时也可以从vmstat中看到这些可用内存是在不断减少的,直到小于了100M以后才有了回收的动作,这个动作也是系统级的动作。

  • 从进程数量上来看,有229个php进程,这个数据量合理不合理,我们接着要计算一下。


从以上分析来看,我们得先解决页交换的问题,再考虑其他,因为这个问题已经导致了25%的cpu消耗,至于业务代码够不够快,那是在解决了页交换之后要分析的方向。


先来计算一下,进程数据对内存的影响。从top上看,一个php进程消耗0.4-0.5%的物理内存,那我们就来算一下:


229x(3.7G*0.5%) =  4.2365 G 

也就是说内存都给了php进程也不会够。


针对这种情况,我们先要做的是把内存使用量降下来,而降下来的比较快的验证方式就是把php工作线程降低,所以这里做了如下修改:

性能分析之进程过多导致的page faults_云服务_13

修改php-fpm可以启动的最大进程数量。max_children 之前是200,修改为60。


  • 优化效果


修改之后的压力数据:

性能分析之进程过多导致的page faults_ios_14

系统资源数据:































































































































top - 17:18:01 up 110 days, 21:31,  5 users,  load average: 63.96, 37.93, 17.35Tasks: 250 total,  66 running, 184 sleeping,   0 stopped,   0 zombie%Cpu0  : 86.4 us,  9.6 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  4.0 si,  0.0 st%Cpu1  : 85.1 us, 10.3 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  4.6 si,  0.0 stKiB Mem :  3881904 total,   248980 free,  2640380 used,   992544 buff/cacheKiB Swap:        0 total,        0 free,        0 used.   413748 avail Mem 
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 23043 ops 20 0 1200016 17564 9268 R 5.0 0.5 0:07.00 php-fpm 23018 ops 20 0 1200020 17508 9212 R 4.6 0.5 0:07.09 php-fpm 23042 ops 20 0 1200008 17780 9448 R 4.6 0.5 0:07.17 php-fpm 23022 ops 20 0 1200020 17444 9140 R 4.3 0.4 0:06.48 php-fpm 23040 ops 20 0 1200016 17904 9564 R 4.3 0.5 0:07.11 php-fpm 10519 ops 20 0 706272 8788 784 R 4.0 0.2 142:34.53 ftrace_udp_agen 23005 ops 20 0 1199940 17528 9200 R 4.0 0.5 0:07.08 php-fpm 23006 ops 20 0 1200020 17420 9116 R 4.0 0.4 0:07.14 php-fpm 23010 ops 20 0 1200020 17724 9392 R 4.0 0.5 0:06.68 php-fpm 23013 ops 20 0 1200020 18464 10116 R 4.0 0.5 0:07.48 php-fpm 23017 ops 20 0 1200020 17788 9424 R 4.0 0.5 0:06.90 php-fpm 23031 ops 20 0 1200020 17488 9168 R 4.0 0.5 0:07.31 php-fpm 23034 ops 20 0 1200020 17456 9156 R 4.0 0.4 0:06.94 php-fpm 25043 ops 20 0 1200020 17196 8964 R 4.0 0.4 0:06.74 php-fpm 23001 ops 20 0 1199928 19640 11296 R 3.6 0.5 0:06.96 php-fpm 23003 ops 20 0 1199968 19540 11184 R 3.6 0.5 0:06.50 php-fpm 23007 ops 20 0 1200020 17500 9200 R 3.6 0.5 0:06.64 php-fpm 23020 ops 20 0 1199976 18572 10252 R 3.6 0.5 0:06.70 php-fpm 23028 ops 20 0 1199996 19368 11020 R 3.6 0.5 0:06.46 php-fpm 25126 ops 20 0 1200020 18952 10608 R 3.6 0.5 0:06.32 php-fpm 22997 ops 20 0 1200012 20044 11624 R 3.3 0.5 0:07.11 php-fpm 23008 ops 20 0 1200020 17604 9240 R 3.3 0.5 0:06.59 php-fpm 23021 ops 20 0 1200012 20304 11924 R 3.3 0.5 0:06.43 php-fpm 23033 ops 20 0 1200020 17540 9224 R 3.3 0.5 0:07.20 php-fpm 23036 ops 20 0 1200020 17404 9100 R 3.3 0.4 0:06.48 php-fpm 23038 ops 20 0 1200020 18312 9988 R 3.3 0.5 0:06.39 php-fpm 24972 ops 20 0 1200020 17176 8952 R 3.3 0.4 0:06.64 php-fpm 25041 ops 20 0 1200020 17648 9324 R 3.3 0.5 0:06.58 php-fpm 25044 ops 20 0 1199940 17420 9028 R 3.3 0.4 0:07.13 php-fpm 23000 ops 20 0 1199916 19188 10876 R 3.0 0.5 0:06.69 php-fpm 23004 ops 20 0 1200020 19032 10636 R 3.0 0.5 0:06.72 php-fpm 23015 ops 20 0 1200020 17972 9668 R 3.0 0.5 0:06.82 php-fpm 23025 ops 20 0 1200020 17524 9212 R 3.0 0.5 0:06.49 php-fpm 23029 ops 20 0 1200020 17732 9428 R 3.0 0.5 0:06.45 php-fpm 25128 ops 20 0 1200020 17656 9332 R 3.0 0.5 0:06.36 php-fpm 22996 ops 20 0 1200012 17508 9208 R 2.6 0.5 0:06.63 php-fpm 22999 ops 20 0 1199960 20104 11756 R 2.6 0.5 0:06.10 php-fpm 23011 ops 20 0 1200020 18976 10580 R 2.6 0.5 0:06.21 php-fpm 23024 ops 20 0 1200020 17552 9228 R 2.6 0.5 0:06.83 php-fpm 23027 ops 20 0 1200020 17980 9644 R 2.6 0.5 0:06.43 php-fpm 24970 ops 20 0 1200020 17192 8968 R 2.6 0.4 0:06.82 php-fpm 22998 ops 20 0 1200056 23176 13580 R 2.3 0.6 0:06.47 php-fpm 23014 ops 20 0 1200020 17876 9540 R 2.3 0.5 0:06.89 php-fpm 23023 ops 20 0 1200020 17924 9612 R 2.3 0.5 0:06.31 php-fpm 23026 ops 20 0 1200020 17432 9128 R 2.3 0.4 0:06.63 php-fpm
[ops@xxxxxxx-null etc]$ free -h total used free shared buff/cache availableMem: 3.7G 2.5G 304M 492M 915M 411MSwap: 0B 0B 0B
[ops@xxxxxxx-null etc]$ sar -B 1Linux 3.10.0-514.21.1.el7.x86_64 (QC_GZ-172_24_19_171-null) 06/16/2021 _x86_64_ (2 CPU)
05:19:08 PM pgpgin/s pgpgout/s fault/s majflt/s pgfree/s pgscank/s pgscand/s pgsteal/s %vmeff05:19:09 PM 5089.11 0.00 34594.06 1.98 42226.73 0.00 0.00 0.00 0.0005:19:10 PM 2752.00 0.00 8768.00 5.00 12707.00 0.00 0.00 0.00 0.0005:19:11 PM 36.00 81.00 5178.00 0.00 14807.00 0.00 0.00 0.00 0.0005:19:12 PM 20.00 0.00 5201.00 1.00 11954.00 0.00 0.00 0.00 0.0005:19:13 PM 3.96 99.01 2734.65 0.99 9546.53 0.00 0.00 0.00 0.0005:19:14 PM 31172.00 0.00 16182.00 31.00 15274.00 0.00 0.00 0.00 0.0005:19:15 PM 372.00 0.00 6103.00 2.00 11231.00 0.00 0.00 0.00 0.0005:19:16 PM 0.00 0.00 2729.00 0.00 10415.00 0.00 0.00 0.00 0.0005:19:17 PM 0.00 0.00 2495.05 0.00 10433.66 0.00 0.00 0.00 0.0005:19:18 PM 0.00 144.00 2569.00 0.00 10672.00 0.00 0.00 0.00 0.0005:19:19 PM 312.00 0.00 2721.00 1.00 9280.00 0.00 0.00 0.00 0.0005:19:20 PM 0.00 0.00 5075.00 0.00 11911.00 0.00 0.00 0.00 0.0005:19:21 PM 0.00 0.00 2566.00 0.00 9630.00 0.00 0.00 0.00 0.0005:19:22 PM 0.00 0.00 5025.74 0.00 11876.24 0.00 0.00 0.00 0.0005:19:23 PM 0.00 708.00 2675.00 0.00 9661.00 0.00 0.00 0.00 0.0005:19:24 PM 0.00 87.13 2526.73 0.00 10161.39 0.00 0.00 0.00 0.0005:19:25 PM 0.00 0.00 5079.00 0.00 11127.00 0.00 0.00 0.00 0.0005:19:26 PM 7080.00 0.00 2565.00 2.00 9749.00 0.00 0.00 0.00 0.0005:19:27 PM 0.00 0.00 2604.00 0.00 10726.00 0.00 0.00 0.00 0.0005:19:28 PM 0.00 27.72 2485.15 0.00 9882.18 0.00 0.00 0.00 0.0005:19:29 PM 4.00 0.00 2961.00 0.00 10431.00 0.00 0.00 0.00 0.0005:19:30 PM 4.00 216.00 5464.00 0.00 11137.00 0.00 0.00 0.00 0.0005:19:31 PM 14636.00 0.00 2859.00 7.00 10539.00 0.00 0.00 0.00 0.0005:19:32 PM 0.00 0.00 5007.00 0.00 10714.00 0.00 0.00 0.00 0.0005:19:33 PM 272.00 2480.00 2907.00 66.00 10642.00 0.00 0.00 0.00 0.0005:19:34 PM 205.94 0.00 2749.50 50.50 9846.53 0.00 0.00 0.00 0.0005:19:35 PM 3448.00 92.00 5013.00 1.00 11160.00 0.00 0.00 0.00 0.0005:19:36 PM 2928.00 0.00 2614.00 1.00 10285.00 0.00 0.00 0.00 0.0005:19:37 PM 0.00 0.00 2589.00 0.00 10545.00 0.00 0.00 0.00 0.0005:19:38 PM 0.00 1072.00 2580.00 0.00 10291.00 0.00 0.00 0.00 0.0005:19:39 PM 0.00 0.00 2531.68 0.00 10008.91 0.00 0.00 0.00 0.0005:19:40 PM 1116.00 80.00 13108.00 23.00 13745.00 0.00 0.00 0.00 0.00

[ops@xxxxxxx-null etc]$ vmstat 1procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st95 18 0 153996 2844 828384 0 0 1280 96 1 2 7 2 89 2 096 13 0 154980 3304 766436 0 0 19568 667 6147 5450 74 26 0 0 0101 3 0 155960 2852 763512 0 0 11004 66 6360 6081 73 27 0 0 089 4 0 183536 2612 768604 0 0 16088 368 6481 6240 68 32 0 0 064 0 0 424340 3072 776676 0 0 13208 80 6666 6661 76 24 0 0 066 0 0 425608 3108 790188 0 0 13440 0 8114 7244 85 15 0 0 061 0 0 426232 3108 790676 0 0 16 0 8467 7874 84 17 0 0 064 0 0 444648 3708 796196 0 0 6164 27 8149 7963 83 17 0 0 061 1 0 445112 3716 798184 0 0 1980 0 9043 8070 87 13 0 0 061 1 0 439120 4136 799028 0 0 928 2904 8986 8419 86 13 0 0 062 1 0 403940 4188 838924 0 0 39688 80 8309 7251 82 18 0 0 065 0 0 401572 4196 839088 0 0 20 0 8794 7971 87 13 0 0 065 1 0 399952 4196 839524 0 0 4 0 8912 8124 86 14 0 0 065 0 0 399804 4336 841156 0 0 1420 0 8937 7970 86 14 0 0 070 0 0 398820 4336 841296 0 0 0 156 8781 8039 86 14 0 0 062 0 0 398756 4364 841616 0 0 20 116 8952 8206 85 15 0 0 062 0 0 399064 4368 841896 0 0 4 0 8915 8095 86 14 0 0 063 0 0 399560 4368 842212 0 0 0 0 9155 8496 85 15 0 0 063 0 0 396260 4368 842520 0 0 0 0 8742 7982 88 13 0 0 061 0 0 398460 4368 842844 0 0 0 8 8841 7885 85 15 0 0 063 0 0 397076 4368 843132 0 0 0 0 8780 8144 85 15 0 0 057 0 0 389512 4388 851948 0 0 8324 64 8737 8014 86 14 0 0 066 0 0 387892 4388 852132 0 0 0 0 9118 8270 87 13 0 0 065 0 0 389280 4388 852328 0 0 0 0 8480 7771 88 12 0 0 065 0 0 388288 4388 851924 0 0 0 4 9037 8192 88 13 0 0 061 0 0 388648 4388 852224 0 0 436 0 8996 8450 87 13 0 0 0

从以上数据可以看出,faults降下来了,us cpu使用率增加了,可用内存多了一些。但cpu的等待队列还是高。

从TPS和RT上来看,TPS没有降到那么低了。

其实这里的线程数还可以再降低一些,就会让TPS更为稳定。


总结

在这两个问题的分析过程中,你可以看到,我都没有直接去看什么代码或SQL。因为我一直在强调一点就是性能分析一定要有证据链

在很多人的脑子里还有一个误区就是应用的线程数是可以按默认值来的,比如说这个例子中的PHP进程数,还有像spring boot中的tomcat线程数。其实很多的应用都用不了默认线程数那么大的值,而这个值过大时,在压力之后会起到负面效应,所以一定要根据应用的实际需要去判断需要多少工作进程或线程,而不是默认即可。


留个思考的空间:

  1. 执行swapoff关掉swap之后是不是就没有交换分区了?

  2. 在本案例中,为什么看了一眼top就会知道执行“sar -B/vmstat/iostat/free/进程数”这些查询动作?用不用再做其他计数器查询动作?