前言： 我在公公号上发的都将是具体的技术点，不会涉及到信息保密条约。也是基于这样的限制条件，有些信息可能会是不完整的。
本文是接前面写的文章《性能分析之IO分析-jbd2引起的IO高》
前文提到了IO高的问题。也解释了原因是什么。后来跟管理OS的团队沟通了之后，他们表示之前不清楚这个参数的限制，也说云服务器嘛，IO本来就差（这合理吗？）。
我把具体的配置参数列出来给他们看了。
/dev/mapper/data_lvm-data_lv /data ext4 rw,relatime,barrier=1,data=ordered 0 0
后来他们改了之后，TPS可以在原场景不变的情况下增加了100TPS。 当然这不是我的目标，我要知道的是系统的瓶颈当前是在什么地方。
上一个场景是：线程5个，没有任何的思考时间。从执行结果看，系统资源都没有用满，所以我决定下一个场景是：
线程10个，其他场景设置不变。在压力的过程中，并没有看到TPS增加两倍到600，而是停在了400左右。其实对于一个java的JVM来说，在大部分的应用场景下能达到400TPS已经算是不错的了。但是我要知道为什么400TPS就增加不上去了。于是，我又接着分析。在场景执行之后，开始看系统资源。
单CPU sys高达86.7%。当然这是瞬间值。但是在监控的过程中发现，这个高CPU的出现还不是一次两次，而是很频繁的高。再看下vmstat
可以看到几种情况出现：
- 偶尔有等IO的情况出现；
- CPU队列已经频繁出现；结合system下的in和cs来看，CPU中断近2万，上下文切换在3万5左右。
从CPU的切换来看，这个值不能算是高，更高的我也见过，能高达十几万。不过在这个云服务器的系统里，单CPU就高达3万5左右，这个CPU也是废了的状态。下面的分析思路就很清楚了，就是看是哪个进程消耗了CPU，进而定位到是哪段代码导致的。所以思路就是：
sys CPU高 -> 进程 -> 线程堆栈 -> 代码调用 -> 提出修改方案
基本上到这个层面，开发都会很尊重你的结果了，不会出现扯皮的情况。
对sys CPU会瞬间高的问题分析之后，发现出现了Spin_lock（自璇锁），在TPS达到近3000左右的场景中，一个4C的云服务器出现spin_lock，也是可以理解的，这时候需要商讨的是，如何部署实例了。
