-
Notifications
You must be signed in to change notification settings - Fork 392
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
关于闲时启动大量import进程消耗机器资源致宕机的问题 #148
Comments
从你的描述看应该是这个应用场景导致了这样的结果,我建议你采用限制 import 进程数据的办法,待其它进程退出后其它 project 再唤起 import. |
刚看了下代码,本身默认限制 5个 import 进程呀?你们是自己改大了吗。 |
|
那你们可以把 db->count 这个条件取消,当时想的是如果数据量少提交也很快就不提示 too busy |
另外问一下,自己通过源码编译有什么环境要求吗?我从官网下载的 并且我改写的部分基本上没问题,而且改的是 之前官网有个帖子 操作系统:Linux Alpine |
我们迅搜每隔几天就会出现一次机器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所以该问题出现的条件是:
当这三者条件同时存在时,此时是闲时,很多租户都仅有db->count少量的未入库数据时,就会启动很多import进行入库。不仅导致了内存占用大,也导致了很大的磁盘IO负载,两者都达到极限后,基本就爆了。。。
所以该如何解决?
所以综上所述,考虑并完善一下import进程数量的限制?
The text was updated successfully, but these errors were encountered: