proxy_pool batch_refresh Schedule阻塞

vptzau2j  于 2023-03-19  发布在  其他
关注(0)|答案(6)|浏览(304)

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。

n53p2ov0

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。

遇到了同样问题

dhxwm5r4

dhxwm5r42#

想了解一下
是完全"无法验证raw_proxy"
还是"验证raw_proxy很慢"

qvtsj1bj

qvtsj1bj3#

想了解一下
是完全"无法验证raw_proxy"
还是"验证raw_proxy很慢"

只是很慢。量化一点的话,感觉是剩1~2个线程在跑。

wfauudbj

wfauudbj4#

解决方案 proxy_pool/Schedule/ProxyRefreshSchedule.py:102

minutes=1 修改成 minutes=30 , 这个时间还是要看 raw_proxy 的大小

w7t8yxp5

w7t8yxp55#

隔了一年多,发现了问题的原因:mongoDB的pop经常返回同一个代理,常常出现几十个线程验证同一个代理,因而验证效率退化为单线程。应该跟$sample机制有关,在个人电脑上没有这样的问题,但在云主机上会有,可能随机数种子的更新和电脑的运算速度有关。

unhi4e5o

unhi4e5o6#

上述版本为1.13, 更换为1.14后问题解决

相关问题