生产问题总结(集群或单节点挂掉)

1.问题

最近一周真是不太平，应用几乎每天都会挂，而且还每天的原因都不一样

2.以下就几种原因简单的说下

1）内存溢出

现象：内存告警，拿不到数据库连接，高full gc

分析：增加jvm参数，full gc时生成dump日志，分析dump日志，发现有一个查询占了内存的60+%。。。，看内存占比前几位的全是string对象，而且全是重复的，

那么就直接去看这个查询啊，一看这个查询的sqlmap，发现里面用了in，而当时生产环境这条sql in后面带了20000+的id去查询db，而db根据id来分库分表，然后根据id，这个sql会落到其中的700+张表，呵呵，那么问题来了，这台应用就会建立700+的db链接和700+的prepareStatement，大量的string对象其实就是这个prepareStatement，每个占了内存的0.03%，700+就占了差不多21%，进而导致整个应用内存吃紧，最终OOM

2）还tm是内存溢出

现象：内存告警，高full gc

分析：还是看应用的dump日志，还是发现有个查询占用了大量内存，不过这次和上次的问题不一样了。。。查询里面用了ibatis的内存分页，而非常悲剧的是，这条sql查询的结果集有600W+，而且查的是整条记录，所以内存再次撑爆。。。

3）服务器内存告警

现象：收到服务器内存监控告警

  分析，立马去服务器上执行top命令，看内存的使用情况，发现应用的进程占了40%左右的内存，排在第二位，而排在第一位的居然是一个root进程，占了50%左右的内存，导致应用的内存不够用，后来查了下，发现是中间件组做的一个日志采集服务。。。什么鬼，坑死了

3.总结

1.系统宕机时，先看下应用的日志是否有OOM的异常，如果有，看应用的dump日志，分析导致OOM的原因；如果没有OOM，则看服务器当时的内存使用情况，看是不是有别的进程占用了太多的服务器的资源，导致应用无法获取资源；

2.写sql时一定要注意，就拿我们的应用来说，ORM框架用的ibatis，一般来说，ibatis的内存分页不建议使用，因为它是将结果集一次全部load如内存，然后再在内存中分页将结果返回，当时结果集很大时，会耗尽系统的内存；sql中的in查询也是，不建议使用，如果非要使用的话，建议限制下in后面所带字符串的数量，比如不能超过1000个；总之一个要控制sql本身的长度，同时也要注意下控制结果集的大小，结果集很大时建议采用分页查询，避免一次查询出过多的数据