jvm 之 国际酒店 8 月 19 一次full GC 导致的事故

事故经过：

1  15:18收到短信报警：国际酒店调用OMS queryGorderOrderList方法失败；成单接口调用OMS获取token失败。

2  查看checkList发现15:18开始发现调用OMS 订单列表接口响应时间明显变长。

3  业务反馈国际酒店MIS系统查询不到数据，也无法导出数据。怀疑是因为这个引起的。

登录ihotelMs系统

IhotelMis调用OMS返回errorCode

总共调用OMS出现问题3000多次，并且还在调用。

4  查看ihotelMs cpu使用率正常，gc也正常。

5  15:27登录OMS一中心机器，CPU使用率60%以上，并且一直full gc，几乎把老龄带内存全部占满。导致OMS服务不可用，

影响其他业务线。二中心的机器没有问题。

6    15:28重启一中心两台OMS，但是过几分钟又挂了。

7    查看日志曾有人在导出国际酒店半个月的数据，大概两万条，猜测是国际酒店的问题。15:38将ihotel的业务都切到outeroms.

然后国际酒店业务正常，查询OMS没有问题。

8   15:56将OMS全部切到二中心。

9    15:59trainAPI也切到outeroms，服务也正常了。

10  16点以后所有服务正常【OMS一中心没有流量】

11  17:45恢复一中心流量。所有业务正常。

事故分析：

国际酒店MS系统大量调用OMS造成OMS服务不可用，进而影响其他业务线。

分析订单导出代码，发现可能造成死循环：

标红线部分代码，一次调用OMS设置的是分页大小是5000，很容易造成OMS返回失败，如果调用OMS返回失败【可能OMS收到请求，已经执行了查询命令，但是因为网络或者别的异常原因没有返回国际酒店数据】，代码会执行continue，重试去调用OMS，如果再失败再重试。。如果正好有几秒钟的时间，网络不好或者因为OMS系统问题没有返回正常数据，这段代码会一直循环调用OMS，这种大量调用造成OMS系统压力大，OMS堆内存使用过多，更加剧国际酒店这行代码收不到正常数据，恶性循环。。最终造成OMS down掉。

解决方案：

1.代码中写continue的作用是为了防止在业务导出数据，多次查询OMS有一次失败，可以进行重试操作,保证拿到的数据。但是会造成死循环，并且查询OMS订单列表底层已经设置了重试机制，双重重试会加重OMS负担。因此去掉continue。

2. 设置OMS分页大小为5000，很容易造成OMS压力过大，因此设置分页大小为500，分多次调用OMS。

薛天俊

OMS国际酒店

事故经过：

1  15:18收到短信报警：国际酒店调用OMS queryGorderOrderList方法失败；成单接口调用OMS获取token失败。

2  查看checkList发现15:18开始国际酒店开始大量调用OMS 订单列表接口，很不正常。

3  业务反馈国际酒店MIS系统查询不到数据，也无法导出数据。怀疑是因为这个引起的。

登录ihotelMs系统

IhotelMis调用OMS返回errorCode

总共调用OMS出现问题3000多次，并且还在调用。

4  查看ihotelMs cpu使用率正常，gc也正常。

5  15:27登录OMS一中心机器，CPU使用率60%以上，并且一直full gc，几乎把老龄带内存全部占满。导致OMS服务不可用，

影响其他业务线。二中心的机器没有问题。

6    15:28重启一中心两台OMS，但是过几分钟又挂了。

7    查看日志曾有人在导出国际酒店半个月的数据，大概两万条，猜测是国际酒店的问题。15:38将ihotel的业务都切到outeroms.

然后国际酒店业务正常，查询OMS没有问题。

8   15:56将OMS全部切到二中心。

9    15:59trainAPI也切到outeroms，服务也正常了。

10  16点以后所有服务正常【OMS一中心没有流量】

11  17:45恢复一中心流量。所有业务正常。

事故分析：

国际酒店MS系统大量调用OMS造成OMS服务不可用，进而影响其他业务线。

分析订单导出代码，发现可能造成死循环：

标红线部分代码，一次调用OMS设置的是分页大小是5000，很容易造成OMS返回失败，如果调用OMS返回失败【可能OMS收到请求，已经执行了查询命令，但是因为网络或者别的异常原因没有返回国际酒店数据】，代码会执行continue，重试去调用OMS，如果再失败再重试。。如果正好有几秒钟的时间，网络不好或者因为OMS系统问题没有返回正常数据，这段代码会一直循环调用OMS，这种大量调用造成OMS系统压力大，OMS堆内存使用过多，更加剧国际酒店这行代码收不到正常数据，恶性循环。。最终造成OMS down掉。

解决方案：

1.代码中写continue的作用是为了防止在业务导出数据，多次查询OMS有一次失败，可以进行重试操作,保证拿到的数据。但是会造成死循环，并且查询OMS订单列表底层已经设置了重试机制，双重重试会加重OMS负担。因此去掉continue。

2. 设置OMS分页大小为5000，很容易造成OMS压力过大，因此设置分页大小为500，分多次调用OMS。

补充一些：

1.当发现oms一中心的服务处于假死状态时，ops操作重启了一中心的服务，但是一起来就挂了，因为这时候ihotelMis还有大量的三级联查（每次5000条）的查询请求打到一中心（办公网请求都会打到一中心）。

2.oms流量切到二中心，请求也会打到二中心，所以出现了二中心的请求量也很高的现象。

3.ihotelMis引用的omsagent的包刚好有问题，打印不出inOut日志，这也影响了快速定位问题。