28丨案例：带宽消耗以及Swap（下）

 

 

上一篇文章我主要分析了带宽消耗，今天，我们来看一下分析的第二和第三阶段，也就是 Swap 分析和数据库分析。

分析的第二阶段

Swap 的原理和对 TPS 的影响

前面有一个扣，是说 swap 多的问题。要理解 swap 为什么是黄的，得先知道什么是 swap。我先画个简易的示意图。

这里先解释一下，对于一个 Linux 系统来说，如果配置并开启了 swap 分区，那么默认的 swappiness 参数是 60。

swappiness 是在内存 reclaim 的时候生效的，而 reclaim 方式同时有两个动作：1. 将 file 相关内存进行回收；2. 将 anon 内存交换到 swap 分区。

所以 swapiness 值越大，swap 分区就用得越多。

对我们现在分析的这个系统来说，来看一下：

我们看到这里配置了一个内存为 8G 左右，已经使用了 7G 多了，swappiness 配置为 30%。

通过 free 看到现在只有 145M 的物理内存剩余，可用内存也只有 254M 了。

所以上面图中的 swap 飘黄也是很合理的喽！

下面我们就针对应用服务器的 swap 来看是不是可优化。

所有人都知道，当 swap 被用的时候，性能肯定会下降，所以在我的测试过程中，一般我都建议把 swap 直接关掉测试性能，有人说这样有什么问题？

那就是没有 swap，让不常用的对象直接占用物理内存，如果物理内存不够用，就把对象删了，后面再创建，这时会增加的是 major fault，那就增加好了，反正是要性能差的。

说得如此硬气，那在生产中怎么办呢？开还是关？有人觉得关了心里有安稳，有人觉得开着心里会安稳。而一个系统、一个容器、一个节点，如果容量控制的非常好的情况下，我建议关掉。开着它，也只是心里上的安慰，不会有 TPS 处理能力上的提升。

瓶颈分析定位

既然知道了上面的大概原理。对一个运行 Tomcat 应用的服务器来说，那肯定是要先检查一下 JVM 设置为多大。先执行 ps 命令，看一下 Java 进程吧。

关键参数如下：

JAVA_OPTS="$JAVA_OPTS -server -Xms2048M -Xmx8192m -XX:PermSize=256M -XX:MaxNewSize=2790m -XX:MaxPermSize=512m -XX:SurvivorRatio=8"

JVM 是 1.8.0_65。

这个参数配置有很大的问题。物理内存只有 8 个 G，一个 JVM heap 就配置了 8G，这让其他的东西怎么玩得起来？并且 JDK 是 1.8 了，配置 permsize 是又为啥呢？

虽说有多个地方配置不合理，但是我们也得要知道一下应该配置多少是合理的吧。

看参数的时候，JMX 也配置上了，那就用工具来看吧。

首先来看一下系统资源。先看一下系统资源在压力下的表现：

队列已经出现，CS 2 万多，in 2 万多，说多不多。我们可以先放着。

I/O 没什么压力，swap 也一直有值，我们要解决的就是它。

us：sy 接近 2：1，这个是不良信号，记在心里，后面再说。

其次再看下 JVM 的情况：

CPU 使用在应用上的时间达到 60%，GC 上没耗什么时间，并且从堆的回收能力上来看，比较正常，只是只用到了 3G 左右，这里有必要给 8G 吗？

线程活动的达到 347，看起来还是在增加的，这里也可能是个问题点，只是现在我们不用关心，它还没跳出来。

从这个 JVM 状态上来看，它完全用不到 8G。在这种状态下，还有另一个 Tomat，并且另一个 Tomcat 中也没有配置 -Xmx -Xms 参数，当没有配置时，默认 -Xmx 是物理内存的 1/4。再加上 thread 用的，所以 swap 飘黄也是吻合的。

优化结果

首先，我们把 JVM 配置成最简，JVM 设置为 4G。

JAVA_OPTS="$JAVA_OPTS -server -Xms4096M -Xmx4096m"

perm 区在 1.8 里都没有了，这几个参数也没啥用。在我的习惯中，MaxNewSize 也是先看要用到多少，再决定配置不配置。有些应用自己不熟悉，也无法直接给出配置，只有测试之后再配置。

各部分配置为多大，都没有定数，要通过测试看需要多少。

而我们现在最重要的是先把性能调整上去，再考虑这些细节内容。这样修改 JVM 就是为了把物理内存使用率低下来，先不修改 swapiness 的比例是为了看下结果，如果用不到 swap 就不再调了，如果还是用了 swap，再来调它。

当我们把 JVM 修改了之后，再执行起来场景。看到内容如下：

CPU 使用率相对前面没有什么变化，但是堆 4G 只用到了 1.5G，可见这个堆连 4G 都用不到。当然我们还是要分析下其他的内容。

还记得我们要解决的是什么问题吧？swap 飘黄了！

从这张图可以看到 Swapping 不报警了！CPU 占用 70% 左右。说明现在 available 的内存是充足的。

这时我们再看一下系统资源，首先是应用服务器系统资源。

应用服务器系统资源 vmstat 如下：

应用服务器系统资源 top：

应用服务器系统资源 iftop:

上图中可以看到，对比之前的资源，swap 基本上没有了，CPU 使用率多起来了。但是队列依旧长，sy CPU 消耗还是有点多了。

应用服务器的 si 已经到了 13.1% 了，这个值要关注下，暂时还不能说是问题，但是接着增加下去，肯定会是问题。

网络已经超过 70Mbps 了，峰值上到 87Mbps，这是一个好事，它说明现在处理的业务量确定多了。

接下来是数据库服务器系统资源：

你可以看到数据库 CPU 都用到这么高了？

TPS 能到 259.2 了，较之前的 221.5 没有提升多少。但是我们解决了 swap 的问题，还是有了一点点的提升。

那下一个瓶颈在哪里呢？通过上面的数据库资源来看，数据库早就已经被用到了 100% 的 CPU，队列也嗖嗖地涨到了好几十，高的都超过 100 了。

可见我们在处理应用服务器的时候，数据库这边已经早就吃不消了。那下面，我们就先把应用服务器的优化部分放一下，再去分析下一个短板：数据库。

后续性能工作建议

但是这里并不是说应用服务器的优化工作就完成了，还有一些部分需要做的。

优化 JVM 配置参数，至于应该配置成什么值，还需要再测试，可能会有人说，这个测试人员怎么知道呢？请你相信，如果这个值性能测试人员都测试不出来的话，一般的架构师也不可能知道该设置为多少。

通过监控分析确定 swapiness 的值。

网络带宽又快到占满了，如果 TPS 再提高，网络肯定又支撑不了。

这些扣也都放在这里。因为我们主要是找到系统的短板，并一一解决，才能使整体的 TPS 增加，虽说现在应用服务器上还有优化的空间，但是现在它不是最短的板。

我们在不忘记应用服务器这些问题的同时，再将目光转向数据库。

分析的第三阶段

瓶颈分析定位

先来看看数据库的系统资源。

我在很多场合都在强调一个词：证据链。所以基本上分析也会是从 OS 层面开始。

但是证据链这个词说起来容易理解，实际上要想真的有链起来的能力，必须具有基础知识，像分析数据库就更明显。因为当我们不了解系统架构时，想说明一个事情就非常困难。

像上面的这个 top，显然 us CPU 使用率非常地高，idle 几乎没有了，只有一个 si 占了 5.7%，这个 si 并不算高，我们在上一阶段看到的应用服务器的 si 都已经达到了 13% 了。

我们说 si 的高或者低，倒不是关键，关键的是它有没有成为我们的瓶颈点。在这个系统中，us cpu 才是我们要关注的重点，因为它实在是太高了。

对于一个数据库来说，要干的事情就是执行 SQL。当分析多了数据库之后，基本上也形成了套路。不管怎么样，还是先看一下基本的监控信息，以下截取一些 Spotlight on MySQL 的有用的图，如果你没有这个工具，用其他的监控工具也是一样的。

从上面的图可以看到，CPU 使用率 99%，Query Cache 是 OFF 的。记下这个位置！

从上图看到，负载队列非常长，但 Disk I/O 没多少，说明队列和I/O 无关，只是 CPU 的队列，非常好！

Network 也不算大，进出每秒 5000 多个包，我们再来看一下网络用到多少了？

峰值也才 70Mbps 左右，即使是 100Mbps 带宽，现在仍然认为有余量（注意！我这里说有余量是因为我同时也检查了网络队列，并没有阻塞，并不是只看了这个值就武断地做了判断）。

通过上面的图可以看到，每秒执行 2500-3000 的 SQL，Sorts per second 达到 800-1000，Sort rows per second 达到 8000-10000。

session 用得倒是也不多，但 Miss Rates 在压力过程中 Query Cache 都是在 100%，并且从最上面的 summary 中可以看到 Query Cache 也是 OFF 的。

为什么没有在看到 Query Cache 是 OFF 的时候就敲黑板呢，这是因为在一些应用中，如果不是查询多的话，这个值 OFF 也不能说有问题，但是在这个应用中几乎所有的语句都是 select，那这个 Query Cache 再不打开就说不过去了呀。这里先记录下这个问题，待会我们的优化动作就是打开 Query Cache。

不管怎么说，对一个数据库来说，主要是执行 SQL 嘛，而对 MySQL 来说，不看 slow log，还能看什么呢。

通过整理 slow log，看到如下内容：

1. # Overall: 280 total, 1 unique, 0.59 QPS, 9.53x concurrency ______________
2. # Time range: 2019-09-26T13:44:08 to 2019-09-26T13:52:06
3. # Attribute total min max avg 95% stddev median
4. # ============ ======= ======= ======= ======= ======= ======= =======
5. # Exec time 4555s 12s 19s 16s 18s 2s 16s
6. # Lock time 52ms 130us 662us 185us 273us 53us 167us
7. # Rows sent 0 0 0 0 0 0 0
8. # Rows examine 30.81M 112.69k 112.69k 112.69k 112.69k 0 112.69k
9. # Query size 186.48k 682 682 682 682 0 682
10. # Profile
11. # Rank Query ID Response time Calls R/Call V/M Item
12. # ==== ================== ================ ===== ======= ===== ===========
13. # 1 0xBED932B8C940697E 4555.0867 100.0% 280 16.2682 0.16 SELECT test2

什么情况？只有 1 unique？0.59TPS？我前面的 TPS 可是有 259.2，这结果一看就感觉不对。

查看一下 long_query_time，配置成了 10s，怪不得看不到慢 SQL。

改 long_query_time 为 1s，再跑一遍。看到如下结果：

1. # Overall: 620.47k total, 30 unique, 259.39 QPS, 16.76x concurrency ______
2. # Time range: 2019-09-26T13:44:08 to 2019-09-26T14:24:00
3. # Attribute total min max avg 95% stddev median
4. # ============ ======= ======= ======= ======= ======= ======= =======
5. # Exec time 40082s 88us 23s 65ms 323ms 649ms 332us
6. # Lock time 61s 30us 363ms 97us 152us 1ms 69us
7. # Rows sent 1.92M 0 633 3.25 21.45 7.43 0.99
8. # Rows examine 987.99M 0 112.69k 1.63k 10.29k 5.49k 420.77
9. # Query size 240.33M 89 1.52k 406.15 833.10 258.19 246.02
10. # Profile
11. # Rank Query ID Response time Calls R/Call V/M Item
12. # ==== ================== ================ ====== ======= ===== ==========
13. # 1 0x160FA75270C56FB8 22892.5442 57.1% 65352 0.3503 0.16 SELECT test1
14. # 2 0xBED932B8C940697E 15914.4501 39.7% 986 16.1404 0.44 SELECT test2
15. # 4 0xF0AE7AFA7851C7E8 245.0176 0.6% 175 1.4001 0.11 SELECT test3
16. # 5 0xFB5A64603A53BFCE 97.2016 0.2% 77 1.2624 0.04 SELECT test4
17. # 14 0x1E088E88CDC208BE 8.7701 0.0% 14 0.6264 0.23 SELECT test5

嗯，这看着顺眼多了。前两个 SQL 占了所有执行时间的 96.8%！第一个 SQL 平均执行时间 350ms，方差 16%。而第二个语句更夸张，平均执行时间 16s，方差 44%。这得收拾！

但是要不要优化这样的 SQL，我们就需要根据 SQL 的分析和业务的分析来判断了。这里我先把执行计划列出来看看。

SQL1 的执行计划：

没有分区。

不包含子查询或者 union 操作。

全表扫描。

第一个表所查有 70 行，第二个表所查有 631 行，此值仅做为参考，并不精准。

第一个表返回结果只占了读取行数的 1.43%（优化点），第二个表返回结果只占了 0.16%（优化点）。

在第一个表中，Extra 有一个值，using where。

在第二个表中，Extra 有一个值，Range checked for each record (index map: 0x1) 。

SQL2 的执行计划：

没有分区。

不包含子查询或者 union 操作。

非唯一索引查找，也列出了具体的索引。

第一个表索引列上有 102570 行，第二个表索引列上有 118 行。此值仅做为参考，并不精准。

第一个表返回结果只占了读取行数的 3.33%（优化点），第二个表返回结果占了 100%。

在第一个表中，Extra 有三个值，using index condition; using where; using filesort。

在第二个表中，Extra 有一个值，using where。

这里我要敲黑板了！！！你是不是不记得 Extra 这些值的含义了？是不是要祭出你的搜索引擎，要开始查了！

我们这里再来回顾一遍。

using where：对结果用 where 子句中的条件过滤。

Range checked for each record (index map: 0x1)：MySQL 没有找到可以使用的索引，如果前面的表的列值已知，可能会部分使用索引。

using index condition：先条件过滤索引，找到所有符合索引条件的数据行，再用 where 子句中的条件做过滤。

using filesort：Query 中有 Order By 操作，又无法用索引完成排序，MySQL 不得不选择相应的排序算法来实现。是不是对应上了前面的 sorts per second？

知道了这些基础知识之后，下面再来看一下，两句语句很显然都有优化的空间，尽量使用 filtered 的比例能大一些，至于能不能用到索引，那就看业务的需要了，如果确实是要查很大的索引，表扫还能快点。所以这两个语句，要丢给开发做业务分析了。

优化结果

对数据库，我们有两个优化的方向还记得吧，第一个是 SQL 语句，第二个是 Query Cache。

我们先做第 2 个，将 Query Cache 开启，看一下效果如何。

mysql> show variables like 'query_cache%';

查看结果如下：

query_cache_type ON

query_cache_size 1048576

再执行起来场景，看系统资源：

效果还不错哦，us CPU 降到了 50% 以下。

网络峰值时能达到 90Mbps 了，又快把带宽占完了。

查看网络队列：

再检查下队列，这时看到已经有接收队列了。

从 TPS 上来看，现在能到 300 多一点，同时网络接收发送加在一起 8M 左右。

后续性能工作建议

接下来数据库的优化方向就是优化 SQL。

当然还有别的优化建议，我们将在后面再说。

总结

这个案例从一个概括的描述开始，到各阶段的分析定位，是一个非常完整的过程。从一个项目的角度上来说，现在是不是性能已经达标，要有两方面的判断。

技术方面来说，显然这系统还有很多优化的空间，我们在文中也留了不少的扣。

业务方面来说，系统是否可以上线，就取决于业务指标了。

但是这个性能是不是已经做得完整了呢？显然还没有。现在只是调了一个节点而已。因为这是在测试环境中做的，硬件环境显得非常简单。线上部署结构也会包括分布式多节点集群等。所以从一个性能项目的角度来说，还远远没有结束。我想如果把这个项目完整地写下来，一本书的容量应该不为过。

从技术细节上来说，通过几个阶段的具体操作，可以让你有一个性能分析定位的宏观感受，这也是这两篇内容的初衷。性能优化是无止境的，我们要做的是以最少的时间和金钱成本，达到最大的优化效果。