性能案例

案例二： 压力上不去
现象： 尚直播，目标6万学员同时在线，当在线学员人数到达16000时，压力上不去了
架构： 2个nginx+多个直播服务
分析：
第一步：排查压力机各资源使用，没发现问题
第二步：排查nginx，发现nginx带宽被占满，占满原因为线上每晚定时备份导致。解决办法为避开备份时间再次压测，问题依旧
第三步：排查应用日志及资源使用，也没发现问题
第四步：通过网络抓包分析也没定位到原因
第五步：再次查看nginx，发现无错误日志，说明压力没到达nginx，所以把要定位的范围缩小在nginx之前
第六步：通过联系压力机所在机房的机房管理员后得知，该机房的压力机有安全行为管控限制，建议更换压力机
第七步：更换压力机后，再次压测，单台压力机可以压到在线学员数5万+， 又因为端口后不够用，压力机再次成为瓶颈
第八步：增加压力机后，顺利达到压测目标

案例三：系统访问变慢
排查： 通过top命令发现cpu使用率100%，先找到cpu高的进程，再找到该进程下消耗cpu高的线程，把线程转化为16进制，通过查看线程栈发现该线程有VM thread字样，由此可以推断可能是垃圾回收导致，我们再通过jstat -gcuitl 发现Full GC 高达6000多次，而且时间还在不断增长，由此可以推断可能是内存泄漏导致，
我们再通过dump内存日志，通过mat查看发现是代码中一次性获取了大量的对象导致内存溢出。

通过jstack也可以定位到死锁问题，通过过滤deadlock关键字