batch_refresh Schedule阻塞

[likenji]

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。

[ghost]

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。

遇到了同样问题

[ozhiwei]

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

[likenji]

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

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

[ozhiwei]

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

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

[likenji]

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

[likenji]

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