xunsearch

xunsearch copied to clipboard

关于闲时启动大量import进程消耗机器资源致宕机的问题

5

我们迅搜每隔几天就会出现一次机器CPU飙高、内存耗尽、磁盘IO大到瓶颈的问题，致使机器宕机，最终排查下来，发现有一段逻辑导致的。 我们发现出现该问题的时间点基本都在深夜凌晨的时间段，一开始以为是有大量的任务在处理导致的，后来发现那段时间各种机器负载很低，访问量啥的也不大，但就迅搜的机器负载大到爆炸，最终通过一些监控信息和日志发现原因是在`commit index data`，在一个短短的1秒时间点内，产生了大量的`commit index data`日志。 对应到`index.c`中`db_commit_check()`方法，该方法会在indexd服务端退出时或闲时被执行，无论是退出还是闲时时被执行，`db_commit_check`都是被执行了，根据记录到的另外的日志信息，在宕机的时间点有过瞬间产生近数百个import进程，import的进程数量也与我们记录的`commit index data`日志条数相符，意味着确实是`db_commit_check`中被循环执行产生了大量的import进程 根据该方法的逻辑判断，里面的`continue`条件全都被绕过了，最终会去执行import 所以该问题出现的条件是： 1. db->count有存量未入库，且这个存量大于0条并小于MIN_COMMIT_COUNT 2. 当前indexd服务空闲，即MIN_COMMIT_TIME时长内没有接收到新的连接，这也符合凌晨用量少的特征 3. 迅搜的project较多（即代码里的user），因为我们的应用是多租户应用，我们为每个租户分配了一个project名，所以整体的project会比较多 当这三者条件同时存在时，此时是闲时，很多租户都仅有db->count少量的未入库数据时，就会启动很多import进行入库。不仅导致了内存占用大，也导致了很大的磁盘IO负载，两者都达到极限后，基本就爆了。。。 所以该如何解决？ 1. 无论是不是闲时，执行fork的场景都要限制一下import进程的数量，并且MAX_IMPORT_NUM是否考虑一下可以通过命令行选项自定义？ 2. 从客户端着手，将每个租户分配一个project的改成使用同一个？以减少project过多的情况？但万一真的有场景需要很多project的情况呢？所以对project数量的限制不太好 3. 从客户端着手，定时保持向迅搜发送index相关的请求，以免其处于闲时状态？但这做法是不是有点太临时了 所以综上所述，考虑并完善一下import进程数量的限制？

Veitor