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.csdn.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个线程开始继续压测，结果：
说明大概和我得想法相吻合，压力不够大！因为其他数据都正常