记一次性能排查

首先影响服务器的性能因素：

cpu：体现为多线程，多进程充分利用多核，提高并发性能

内存：现在内存的访问速度很快，ips不高的话，性能不是问题，内存不足时，系统会内存置换，比较影响性能

网卡：网络流量打满了网卡，多余的请求就没法被处理。

安全锁：锁本身并不会影响性能问题，锁的等待比较影响。

同步阻塞IO：如果某一个同步操作很费事，所有的后续操作被阻塞到这个地方，所以现在针对IO密集型服务，异步才是最高效的方式。

问题排查如下：

该系统是一个io密集型的，项目代码基于Disruptor的有限状态机的异步框架，内部不会有锁的竞争，所以排除锁。我们自己实现了异步的redis客户端，同步的操作只有访问mysql， 最终需要执行mysql的操作很少，而且mysql操作改成异步比较麻烦。先从cpu，内存等着手处理。

查看系统资源监控，cpu的idle长期处于70%，看来cpu的利用率不足，系统本身是多线程的，线程数可配置的，上调1.5倍的线程数，重启观察1天，发现没有什么明显的改善，还是有报警，cpu问题排除。

服务部署了2个机房，我比较了下两个机房的配置，A机房的内存64g，cpu也好，B机房32g，cpu差点，A的流量比B的少很多，首先直接系统是无状态的，修改下游的路由策略，改为不限定IDC，权重一致，使流量均匀，(我们内部有一套软件，通过分布式路由控制可以做到),上线后A机房的报警明显减少了，B机房由于流量增大，之前没有的现在有了部分报警。问题看上去得到缓解。

后续上线了新的功能，这次会增加和下游服务多了一次udp通信，这次上线后，报警就多了，error数有时候到了100多，这下问题就需要继续排查了。丢包，是因为接受的udp没有及时处理。调低单个实例的权重，选一台机器在上面部署两个实例，上线观察，恢复回去，问题又重新出现，通过比较发现，问题的确是系统处理速度太慢。看看内存占用，不到20多G，还很宽松，不是内存引起的， 网卡流量也还不到一般，网卡排除。

系统没什么大的变化，难道是代码新功能有耗时的地方，回滚了几台机器，观察回滚了也没啥效果。我也是没啥头绪，思考再三，先放着，暂时不影响业务。放置了几天。晚上下班，想起来，同步操作除了mysql访问，还有日志，我接手这个系统时，的确是逐渐加了一些日志。线上日志的level时INFO，再调高到WARN试下，上线后观察，error不出现了。看来的确是log输出影响了性能。问题目前来看得到了彻底的解决。但日志太少的问题，后续我们会有新的工具来实现分布式追踪。

后续我又想了下，这个问题一开始我的思路也是错了，这个系统本来规模就挺大，我自己首先就排除了业务增长导致的性能压力，我接手了半年，半年里我司也是卖出了好几千万台手机，每个手机都要连入我的服务，所以业务应该是的确增长了一些，导致的性能压力。很多时候，问题最后没法解决，可能是自己把正确的解决方案先排除了。

由于半路转的java后端，在这些问题排查方面经验不足，特记录一下，也算是一次经验吧。