在最近两周, App 在晚上 8:45~11:00 期间, 严重卡顿. 数据加载非常缓慢.
排查与发现:
测试同学抓包查看请求响应, 发现有些请求响应还是正常毫秒数, 有些耗时 n 多秒, 甚至超时. 并且耗时超时请求并不是集中在某几个 url.
pinpoint 系统查看各个服务的响应情况, 发现有些服务响应比较慢, 有些服务响应是正常的. 其中响应慢的服务是用户服务, 很多业务对该服务都有依赖性, 调用量比较大, 处理方式是增加服务. 而 App 中加载慢的现象比就多体现在资讯文章服务. 因为在打开 App 的使用过程中, 多出地方都展示了文章, 该服务的调用次数是比较多的. 但从 pinpoint 系统看到文章服务响应是正常的. 这时候初步断定不是内部服务拖慢了响应, 那很可能是外部因素, 例如 nginx, 域名解析, 带宽等. 域名解析使用的是阿里云的云解析, 一般不会有没问题. 初步推断是请求量增高超过 nginx 的请求量上限, 或者带宽不足.
带宽让运维同学在阿里云管理后台看了. 并没有频繁到达上限 (购买的服务器带宽是 12M), 应该不是带宽问题. 如下图
带宽. PNG
服务器磁盘 io 如下图, 也非常低
iostat.PNG
检查服务器状态, 内存占用 70%(部署 ng 的服务器还部署了一些业务服务), CPU 利用率 15%~20% 之间. 服务器压力其实不大.
CPU 内存. jpg
检查 ng 负载. App 请求通过域名解析分发给三台 ng 服务器 (4 核 8G). zabbix 监控显示, 晚上高峰时间段内, nginx 活跃连接数从闲时 7k 每台攀升到 11k. 判断可能是 nginx 处理能力不足.
服务器网络情况, 可以看到 established 值跟 zabbix 监控中 ng 活跃数差不多一致, fin_wait2 状态数过多. FIN_WAIT2 状态就是服务端在主动发起断开的连接请求时, 发送 FIN 并收到客户端的 ACK 进入的等待客户端 FIN 的状态. 验证了 nginx 处理能力不足.
nestat.PNG
验证方法:
挑个工作日下午 5 点, 停掉一台 ng, 观察到 App 很快就加载缓慢, 症状跟这几天的高峰期一样. 基本验证了 nginx 服务器处理性能问题.
解决方案:
优化 nginx 配置
考虑再部署一个 ngxin 实例来分流
顺便撸一波 tomcat 配置, 检查出确实也有少数服务的 tomcat 没有优化.
负载比较高的服务, 多部署一台实例.
来源: http://www.jianshu.com/p/f300b4983071