CPU使用率过高、响应时间延长：探讨数据库性能与连接池问题的影响

cpu消耗过高的问题

 

 类似：

2、开了一个饭店，客人多，服务员很忙，就很正常

2、开了一个饭店，客人很少，但是服务员每个人都很繁忙，这种现象不正常

压测场景：

30个线程

 

 

 

 发现CPU已经很高了，使用占到99%了

这个时候我们提高线程到40，由于CPU已经到99%,再怎么提高线程，压测后其实TPS没有多大效果提升，响应时间可能会涨

说明你的瓶颈就是CPU，CPU降下来，TPS肯定会上升

我们首先要看哪个进程占的cpu高(我们压的是tomcat，所以不能有别的进程占CPU高，没有别的项目影响我们)

top   --查看cpu哪个进程高

用工具定位CPU，分析问题

 

 

线程死锁，阻塞都是可以通过这个软件看见的jprofiler

我们必须要有2个端，Linux  + window (因为自己用的是wind)  需要将他们联系起来

linux 安装 jprofiler

解压：tar -zxvf jprofiler_linux_11_1_4.tar.gz
进入解压目录： cd jprofiler11.1.4/
运行： bin/jprofiler

3、安装完成运行

http://pan.baidu.com/s/1gfBJ0kV

jprofiler_linux_9_2.sh

 chmod +x jprofiler_linux_9_2.sh

我这里的路径是： 

/opt/jprofiler9/bin/linux-x86/libjprofilerti.so

 

 需要添加参数(tomcat启动，添加到tomcat，别的服务启动，就添加到对应的启动服务里)

 

 

安装window 客户端的jprofiler

 

keyGen.exe去找key

 

 连接服务器的CPU

 

 

 

 

 

 

 

 远程连接地址：

 

 

 

 

 

 然后点OK

连不上，可能是防火墙的原因或者是tomcat原因

下面表示连接上了

 

 

 

 

 重新开始压测：

观看jprofile谁占的cpu是最高的

 

 

 Gjson占了57%  被调用5849980次

再看看其他数据

 

 

 CPU很忙,但是60%花在了Gjson上了

 

 

 此时，响应时间少，吞吐量达到290

此时，现在不用Gjosn，重新压测看看

 

 

 

 

 

 

 

 

 

 发现TPS达到了9百多，并且CPU还没达到90，说明还可以加线程，往下压测，性能得到了明显得改善！TPS翻了4倍！

总结：

 

 

响应时间长:

 

 

 

不消化cpu，而且响应时间很慢

看nginx和tomcat日志，看响应时间，缩小范围

20并发：

 

 

 

 

 

 cpu只用了%10不到，但是响应时间却耗时400多毫秒左右(刚才压得时候是20多)，明显有问题，看GC也没问题

 可以用jprofile去看 看，因为tps比较低，响应时间长，这个时候就可以用jporfile，因为你现在已经就很低了

 

 结果就一目乐然了，这个方法占时很多，一半先看total顺序，然后再去看Media time 中位数

 我们还可以看看call tree ，结合去看，到底谁调用它了，它调用了谁了

 

 再回过头来看看 method static

 

 我们看看源码就知道为什么具体这么慢了。。

 

 

 

  

数据库性能问题 - 慢查询：

见pdf,已经写的很详细了

 

 

 压测案例：

dstat -tcmnd --disk-util  监控服务器  (正常)

 

 

 

jmeter 监控情况:

 

 

 

数据库所在服务器:

 

 

 cpu很高很高，很明显这是有问题 的。。。我们怎么排查呢?

 

 

 sql 监控就是慢查询的pdf 方法

/etc/my.cnf

 

 重启Mysql 

 

 慢查询日志，最好在这个路径下，因为写在别的路径下，可能Mysql没有读写权限！

 /var/lib/mysql/slow.log

数据库去查询这个sql语句。

1、首先找出比较大得sql语句，然后用explain分析一下

2、然后再通过工具看这个表得索引情况，入下图：

 

 

 

 

 

 type 解释：

 

 

 

图上type类型，由上往下，性能越来越低 

type:ALL  没加索引，全表扫描，像新华字典一样，一页一页往后翻

 

联合索引:

命名规则：表名_字段名
1、需要加索引的字段，要在where条件中
2、数据量少的字段不需要加索引
3、如果where条件中是OR关系，加索引不起作用
4、符合最左原则

https://segmentfault.com/q/1010000003984016/a-1020000003984281

联合索引又叫复合索引。对于复合索引:Mysql从左到右的使用索引中的字段，一个查询可以只使用索引中的一部份，但只能是最左侧部分。例如索引是key index (a,b,c). 可以支持a | a,b| a,b,c 3种组合进行查找，但不支持 b,c进行查找 .当最左侧字段是常量引用时，索引就十分有效。

两个或更多个列上的索引被称作复合索引。
利用索引中的附加列，您可以缩小搜索的范围，但使用一个具有两列的索引 不同于使用两个单独的索引。
复合索引的结构与电话簿类似，人名由姓和名构成，电话簿首先按姓氏对进行排序，然后按名字对有相同姓氏的人进行排序。
如果您知 道姓，电话簿将非常有用；
如果您知道姓和名，电话簿则更为有用，
但如果您只知道名不姓，电话簿将没有用处。

所以说创建复合索引时，应该仔细考虑列的顺序。对索引中的所有列执行搜索或仅对前几列执行搜索时，复合索引非常有用；仅对后面的任意列执行搜索时，复合索引则没有用处。

http://blog.****.net/lmh12506/article/details/8879916

 

 

 

 

 

 

 重新压测：

cpu正常，TPS低，响应时间短

 

 

 

 

数据库性能：连接数

案例：

先用10个线程去压测接口：

 

 

 

 CPU 没达到90多以上！吞吐量437左右

我们再用20个线程去压看看，因为CPU还没到极限，所以我们继续往下压得话，TPS一定会增长

 

 

 

 我们发现CPU还是没有用完，TPS增长缓慢，到达545

我们再用30个线程去压试试看：

 

 

 

 CPU只用到了80左右，TPS同样增长缓慢

40个线程去压：

 

 

 

 CPU只用到了80左右，TPS同样增长缓慢，达到641

用50个线程去压：

 

 

 

  CPU只用到了80左右，TPS上不去，但是CPU一直还有20%

 cpu还好，只用了80左右，util也不是很频繁，才50%而已，可以接受，但是tps再怎么压也压不上去了，那么问题出现在哪呢，我们可以看下CPU消耗在哪里和线程的情况

cpu消耗具体每个占用情况，用jprofile 可以看

 

GC也很正常 

 

 看线程状态：

 

 发现有大量得等待线程。。

线程消耗： jstack pid   (这个都是快照，可以多搞几次 ，比如jstack pid >my.log,jstack pid >my1.log , jstack pid >my2.log)

关注线程状态，这里需关注TIME WAITING

关注业务线程，很长  cn 的包或者是org的包主要是

系统线程一直time waiting很正常，业务一直time waiting 就不正常了

 

 上图的连接池为什么要等待呢？

并发数太多，连接池太少，很多连接池的连接再等待

发现最大得连接数才5个，原来是这个原因

 

 

 

 

数据库查看可支持最大链接数：

show variables like '%connections%';

show variables like '%thread%';

 

netstat -anp |grep 3306   查看当前链接数

 

 

重新压测后，发现，虽然也有time waiting ,但是信息很短，没有和业务相关的

 修改最大链接数为50个，重新压测，压测结果

在自己笔记本上线程50，80，100个压测时，服务器CPU总是还有20%左右未使用，那么感觉压力还不够，通过在在自己笔记本jmter 150个线程，服务器100个线程开始继续压测，结果：

 

 

 

 

 

 说明大概和我得想法相吻合，压力不够大！因为其他数据都正常