再一次oom的记录

上一次oom的记录在一次排查OOM的总结，这次oom的排查大概花了一天不到，和leader一起，我这边主要是根据后台刷新日志排查相关代码，复现问题。

这次的oom出现的问题还是不大一样的，具体描述是线上系统连续运行大概三周，本应该是每两周要停服维护一次的，后来在凌晨两点左右，群里有人喊宕机了，然后运维同学反馈说是oom，查看到应用进程因为占用过多内存导致被kill的。

登陆后台管理系统，查看应用进程的内存消耗相关采集图，发现是一条下降的曲线，这里应该是有内存泄漏，而且是缓慢的。然后查看系统日志，发现没有明显的错误和警告，然后通过相关的代码注入dump此时系统内的一些资源快照，也没有发现明显的特征。然后通过一些指令统计所有的lua vm信息，其中有若干个野外场景占用内存过多，平时在没有玩家在该场景中时，大概在一百来兆，现在有的是几GB，很明显是有问题的。

其中后台日志中，有一些打印的info级别信息，其中有一条相日志较多"can not create monster"，但是这里只是表示无法在场景中创建更多的怪。很早之前，大概在2017年底，因为在准备新项目，所以这块我优化过， 主要是因为在场景中怪的数量不能多也不能少，即死掉一只再定时创建一只，原先做法是拿场景中所有的entity比较，是否是怪，是哪个类型的，所以觉得这块线性时间操作的实现没必要，故对类型数量作了cache，即死亡时减一，增加时加一，在创建时取一下有多少，然后算出能创建多少，不用再线性时间比较。(因为要for循环，一般情况下野外场景有一百来只怪，再加上一些玩家，平均情况下比较两百来个，不包括其中的一些get方法等操作)。

后来怀疑是否场景中怪数量过多，或者没释放等一些可能的原因。是不是之前优化的出问题？因为该系统已经在多个平台跑了很久，按理不会出现创建怪出现不平衡的，所以还是加了些日志，定时统计怪的数量，并在相关代码处加其他信息，后来开始复现，修改配置文件，调整刷新间隔和数量，想办法尽快复现线上问题，加一些机器人，去相关场景并击杀怪，测试好几次，每次跑好一会，中途leader说顺便看一内存有没有增加，用相关的工具快照几次对比下内存是否有增加，虽然后面确实有一些增加，此时开始怀疑到跟定时器相关的问题，但不确定。

后来grep线上日志文件，出现内存泄漏的某个场景的内存占用从32MB->64MB->128MB->312MB->514MB->1617MB->3433MB的日志，其中有些增长时间间隔过久，就看了下从312MB->514MB和514MB->1617MB中间的日志情况。其中当312MB->514MB时，隔了一天不到，某条"can not create monster"日志有180万条，当514MB->1617MB时，隔了八天左右，有1700万条，差不多每天200多万条，即跑了这么多次的定时器。

后来查看底层基础代码，其中定时器的实现，之前有同事给某处代码注释说明过，即要置nil以顺利gc回收，但该接口还是要调用的，即删除timer的key，猜测问题出现在这里。因为之前在使用接口时，有说过要单独remove掉相关的key，但不像野外场景那样，长驻内存，并不是副本类的只是临时的。

此时，leader已经找到原因了，是这里的问题，底层基础代码写的不对，所有版本都有这个问题。因为一次性定时器回调后没有把key删除，导致全局定时器管理结构非常大非常大，key占用更多的空间。后来leader重新修改了相关的实现。回头想想，因为在使用基础代码时，即申请资源在内部管理，释放资源由申请者释放还是由内部释放？如果像上面的问题那样，用完不释放，可能就有问题。可能在平时的代码中或更早些不是熟悉这种实现时，再或者因为早期是这么写的，后来因为底层实现修改过后，并没有把上层业务层代码使用方式也一并修改过来，导致这样的情况。还是要多测试，不管是功能性的，还是系统性的，都要覆盖全部路径，虽然很难。

结论：
对于这种不明显的内存泄漏其实很蛋疼的，需要在线上跑很久，或者触发一些条件，比如这里的需要击杀怪，而且要击杀很多只。在刷新间隔比如一秒，人越多，击杀越快的情况下，问题就暴露越早。
出现问题时，能有序的从各方面去定位和排查问题，很重要。
底层基础代码，也可能会有老bug存在。
lua方面的内存泄漏排查工具不是很丰富，不像c/c++语言这些，而自己对于lua这块也不是很熟悉，这块以后再加强些吧。