事故时间：
2016年12月6日
事故现象：
APP端热卖美食链接打开提示“无推荐餐厅”
事故原因：
1. 日志使用的同步写，没有用异步写，并且开启了可以下线的syslog。
2. 以下三个原因导致GC频率高，并且Young Gen转移到到Old Gen以后容易导致Old Gen碎片化严重，引发Full GC。
a.单条日志体较大，容易造成内存碎片。
b.大量HashMap存在内存中,HashMap本身内存使用率不如数组效率高。
c.单个请求耗时较长（高峰期upper95时间达到300ms左右），导致内存不能快速释放，从而升级到Old Gen，而在Old Gen中太大的内存容易导致碎片。
事故定级：
[P4]
事故责任人：
数据运营部
事故复盘：
11:06 Noc反馈大屏热卖美食qps监控指标曲线异常。
11:13 DT（大数据）执行回滚[第一次回滚，此次回滚版本错误]。
11:21 Noc测试热卖美食入口，安卓手机首页的热卖美食是可以打开，ios手机首页热卖美食打开提示异常。
11:25 架构师反馈需要加业务指标，大屏的监控指标难以反映异常状态。
11:29 DT（大数据）执行回滚[第二次回滚]。
11:34 热卖美食接口降级。
11:37 后台业务研发反馈首页的热卖美食入口已经替换成一元霸王餐。
12:14 架构师反馈很多的thread夯仔写日志上。
12:15 DT（大数据）反馈异常原因找到，是执行回滚版本时第一次出错。
12:33 架构师反馈get_guess_you_like_banner dt.hotfood调用量是从哪里进来的
DT（大数据）反馈从app的发现页，如果热卖美食入口异常，发现页的显示热卖美食界面就消失。
13:34 DT（大数据）加入异步async日志同步。
13:41 后台业务研发反馈热卖美食入口已经恢复正常。
13:49 后台业务研发首页霸王餐替换成热卖美食。
改进措施：
1、async写log。
2、gc策略调整。
3、timeout机制调整。
4、扩容机器（暂时）。
5、大屏业务指标拆分开。
6、代码层面优化：
a.压缩日志大小，算法Feature Log只打印前20条记录。
b.提高Rank性能，下线耗时较高的三个算法版本，等待优化完成再上线。
c.代码层面减少HashMap使用，提高内存使用率。
7、Etrace增加GC 数量告警。
事故现场：
1. 事故期间响应时间变化曲线
2.期间GC曲线变动
3. 日常正常情况下请求响应时间
4. 日常正常情况下Rank核心逻辑耗时
事故上下文：
热卖美食目前需要输出大量Feature Log到磁盘，12月6日的时候还是使用的同步写日志方式，并且日志较大，一方面容易产生较多大块内存，不利于内存快速回收。
另一方面增加了请求响应时间，也间接影响内存回收。优化的方向还是从两个方面入手，一是减少日志大小。二是优化Rank速度，提高响应时间。
注：
1.运营事故分级规范 v 1.2
2.关于事故赔偿规范及流程