7D群讨论记录1：TPS从300到750的过程

作者：小鹏

前几天在7DGroup的群中，小鹏同学提了一个问题。

群里一顿讨论。终于有了优化的结果。小鹏特此记录。

先画一个架构图：

画架构图是为了知道请求是从哪里到哪里，做性能分析一定先画个图，脑子里就会有路径的概念了。

• 问题1：TPS呈锯齿状，忽高忽低

直接上图如下：

163服务器（4c/8g）,cpu使用率在60%左右，15分钟负载没有超过cpu总核数，因此163服务器表现良好。还有上升空间。

164服务器（2c/4g）本身配置较低,cpu使用率在60%左右，15分钟负载跟cpu总核数基本持平。可作为优化点考虑。

106服务器（4c/8g）cpu使用率在60%，15分钟负载也没有超过cpu总核数，表现也算良好，还有一定的上升空间。

107服务器（2c/8g）cpu使用率已经达到100%，15分钟负载已经超过CPU总核数一倍，明显已经压满了。

数据库服务器（8c/16g）CPU使用率在30左右，15分钟平均负载2低于CPU总核数8，明显压力没在数据库上。

询问开发后得知，在该项目中加入了动态流量分布（备注如下），了解了动态流量分布的代码逻辑之后，发现tps的锯齿状的间隔时间正好是30s，tps锯齿状的原因是动态流量分布导致的。虽然在将流量分给空闲的服务器的时候，tps是高了，但是从配置低的107服务器来看，不管有没有将它的流量分走，它都是撑不住的。

• 优化方案：

将107下线，找一台和106配置相同的机器做测试。

备注：动态流量分布即根据实际服务器的负载以及CPU使用率，动态的将流量分给相对空闲的服务器，每30s一次做轮询，轮询发现A服务器CPU以及负载过高，接下来的30s会将流量引流到空闲的服务器上。在做轮询的同时，流量是均匀分布的。

• 问题2：调整数据库参数

针对问题1将107下线，找一台和106配置相同的机器做测试，还是测试相同的接口。

从全局监控角度来看，tps达到610/2=300多，服务器的CPU使用率约占到60%，且各个服务器并没有出现负载，由此可见服务器均没有压满，还有上升空间。

但是使用MySQLreport来看，发现有几个参数需要做下调整。

InnoDB Buffer Pool 这个参数值使用率到了100了，肯定是到了瓶颈。

Tables这个值也用到了100%，这块需要修改下。

Query cache没有开。Block Fragment达到 100%

Block Fragmnt：是指内存块碎片，如果你有一个返回超小结果的海量查询，默认的块大小(即4KB)可能会导致大量的内存碎片，这个时候，需要降低"query_cache_min_res_unit"的值，比值越大，碎片越多，一般不建议超过20%。

• 优化方案：

先调整下InnoDB Buffer Pool

show variables like 'innodb_buffer_pool%';
SET GLOBAL innodb_buffer_pool_size= 1207959552; #调成1g，后面又调整成了2g，需要根据实际情况调整

再调整：table_open_cache和query_cache。

set GLOBAL table_open_cache = 1000;
set GLOBAL query_cache_type = 1;

或修改配置文件：

sudo vim /etc/mysql/mysql.conf.d/mysqld.cnf
innodb_buffer_pool_size = 2G
table_open_cache = 1000
query_cache_type = 1

调整mysql配置参数之后，tps还是不高，大概640/2=310多，看来数据库不是性能瓶颈，而且tps还是不规律，还是每30s就波动一次，建议把动态分配流量去掉之后再测试。

调整mysql参数之后的Msyqlreport数据：

• 问题3：网络队列

去掉动态分配流量之后，还是相同的接口tps较为稳定400左右。

发现问题：所有服务器各个指标的使用率都不高，但是crm和mysql之间的互相出现队列。需要查找下原因。

查看106服务器网卡中断信息。

watch -d -n 1 "cat /proc/softirqs"

发现net_rx分布不均匀，只有一个在忙，剩下三个都在偷懒，

但是si不算太高，可以先不处理（将106物理机换成虚拟机）。

接着分析。

tps仍然上不去，但是到106和123服务器上执行top命令再按1后发现us的使用率在个别CPU上面冲到了100，但是第三个cpu的使用率才为1%，很明显CPU使用率分布不均匀呀。

于是使用打印栈信息的命令（如下）找到了CPU使用率较高的一行栈信息，定位到了java的47行代码。给到开发之后，顺利解决。

top  #查找到cpu高的pid
top -Hp 12941   #寻找pid是12941的相关线程
/usr/java/jdk1.8.0_102/bin/jstack
jstack -l 12941 > 12941     #打印12941的栈信息
printf '%x\n' 12951   #将线程12951转换16进制
printf '%x\n' 13084
vi 12941   #进入栈文件，寻找16进制的信息

通过java visualvm链接之后，点击线程dump按钮，搜索关键词mysql ，发现当前有直连mysql的线程，是名叫pool-6-thread-x 的线程，并且发现它只有4个，而且从线程运行状态来看，这几个线程全绿，明显压满。怀疑是线程数量不够用导致。

• 优化方案

将该线程增加到8，结果如下。

Tps由之前的500左右。

增加到750左右。

将线程数量加大之后，发现tps虽然上去了，但是仍然在crm和mysql中间存在队列，这里一个潜在问题---网络。

• 问题4：网络带宽不足

查看各个服务器的实时带宽。

机房简易布线图：

查找交换机B型号：tp-link TL-SL1226的相关参数。

该交换机存在2个千兆端口，24个百兆端口

背板概念：我个人一直理解成电脑的总线。

背板带宽计算方式：每种端口的速率乘以端口数量之和，再乘以2。

由于进入交换记得端口使用了一个千兆端口，而进入这个端口的流量是由上个交换机的百兆端口分出来的，所以在计算过程中把他当成百兆端口来处理

知道了该交换机的背板带宽是8.8Gbps

套用计算公式

（25x端口速率+1x1000）x2=8.8Gbps

算出上游的端口速率=140Mb/s，所以下面的分流不能超过140Mb/s

计算47+47+35=129（由于该交换机下面还有其他的机器，使用到了流量。由此可见，网络基本被用光。）

交换机硬伤，日后再解决。

• 问题5：数据问题

在持续的压测过程中发现问题：tps存在有规律性的激增，同时也观察到了jmeter出现报错信息。

分析原因：是因为数据中有一串用户查不到信息，导致接口报错，瞬时的tps比较高。

优化方案

1. 开发处理500报错。
2. 使用正确的用户数据。

将后台的报错信息处理完之后，tps波动范围较小，相对稳定了。

• 结论

一系列优化之后，从300tps优化至750tps。

在这里，我们只是先优化了一部分应用问题。对于一个性能项目来说当然还没有结束。

后续定位和优化方向：

1. 流量分配
2. 物理网络带宽
3. 资源使用率的具体。

对于性能来说，没有没有瓶颈的系统，性能无止境，且行且调优。