1.背景
最近遇到了一个web服务超时不能访问的问题，用户访问系统不定时返回504（超时）页面，导致用户的访问异常，需要定位并解决这个问题。
2.排查过程
遇到服务响应超时首先想到的就是服务响应不及时，请求处理不过来。可能与以下几个原因有关：
1.CPU负载过高，导致请求处理不过来
2.网卡的带宽被打满，导致网络处理能力不足
3.系统内存不足，请求无法响应，导致系统运行缓慢
4.某一块代码存在大量计算逻辑，导致部分服务接口响应缓慢
ps：由于我们的服务有backup，所以在发现问题之后，我们先下线了有问题的机器，保证服务在线稳定运行，然后对有问题的机器进行问题的定位和分析。建议在保留有问题机器的相关堆栈以及线程信息等现场，然后尽快通过重启来让服务进行恢复，接下来可以逐步分析异常原因。
2.1 CPU
通过top 命令查看机器的cpu负载 都在0.2以下，cpu使用率在10%以下 ，所以不是由于计算资源导致的查询服务响应极其缓慢。
2.2 网卡
通过查看网卡的监控，发现网卡的流量很低，并不存在网卡打满导致请求服务无法响应的情况。（曾经遇到过异步调用而且连接未关闭导致千兆网卡的机器被打满的问题，导致服务存在大量超时）
2.3 内存
2.3.1 是FGC？
第一反应就是jvm可能在进行fullGC，需要使用jstat查看jvm的FGC情况。使用
jstat -gcutil <pid> 1000 60
去查看jvm的状况。然后发现jvm果然在进行频繁的fullGC，如下图（下图中参数含义的说明很多地方都有）：
2.3.2 查看导致FGC的对象
使用jmap存在哪些大对象，导致一直在触发FGC，并进行针对性的优化。使用的jmap命令如下：jmap -histo:live <pid> | head -n <num> 获取目前应用中存活的实例有哪些：
可以看到是存在大量的ByteArrayRow触发了FGC，接下来就需要确认下究竟是在哪个环节有导致产生了如此多的ByteArrayRow。
2.3.3 排查导致FGC的原因
首先把nginx服务器上显示504的请求找出来，504响应时间点首次出现，那么大概率就是这个接口导致的，详细排查发现是我们这边的一个请求需要获取一个很长时序范围内的数据查询，我们没有对时间范围进行限制，导致查询需要load千万级的数据出来，导致瞬间生成大量的对象，导致触发FGC。
确认问题产生的原因之后，就可以针对产生问题的原因做业务上和jvm参数上的调整和限制啦！
