WARNING:apscheduler.scheduler:Execution of job "batch_refresh (trigger: interval[0:01:00], next run at: 2018-12-11 13:14:33 CST)" skipped: maximum number of running instances reached
在验证raw_proxy的时候,常常发现raw_proxy堆积,同时伴有以上错误提示。同时会发现refresh新代理感觉回到了单线程的情况。
一旦raw_proxy不堆积,便不会有报错,很奇怪。
求个解决方案。
目前的解决方案是一旦人工发现堆积情况,便新开一个进程,这样就会很快地验证完raw_proxy。
6条答案
按热度按时间n53p2ov01#
WARNING:apscheduler.scheduler:Execution of job "batch_refresh (trigger: interval[0:01:00], next run at: 2018-12-11 13:14:33 CST)" skipped: maximum number of running instances reached
在验证raw_proxy的时候,常常发现raw_proxy堆积,同时伴有以上错误提示。同时会发现refresh新代理感觉回到了单线程的情况。
一旦raw_proxy不堆积,便不会有报错,很奇怪。
求个解决方案。
目前的解决方案是一旦人工发现堆积情况,便新开一个进程,这样就会很快地验证完raw_proxy。
遇到了同样问题
dhxwm5r42#
想了解一下
是完全"无法验证raw_proxy"
还是"验证raw_proxy很慢"
qvtsj1bj3#
想了解一下
是完全"无法验证raw_proxy"
还是"验证raw_proxy很慢"
只是很慢。量化一点的话,感觉是剩1~2个线程在跑。
wfauudbj4#
解决方案
proxy_pool/Schedule/ProxyRefreshSchedule.py:102
minutes=1
修改成minutes=30
, 这个时间还是要看raw_proxy
的大小w7t8yxp55#
隔了一年多,发现了问题的原因:mongoDB的pop经常返回同一个代理,常常出现几十个线程验证同一个代理,因而验证效率退化为单线程。应该跟$sample机制有关,在个人电脑上没有这样的问题,但在云主机上会有,可能随机数种子的更新和电脑的运算速度有关。
unhi4e5o6#
上述版本为1.13, 更换为1.14后问题解决