RAGFlow版本：0.24

问题现象

在新部署的RAGFlow上传完文件后，点击文件解析，有时候文件会卡住很久，没有任何进度变化，但是手工停止重新点击开始后，解析任务又能正常开始，或者等待很久之后任务才开始运行

RAGFlow这个测试环境没有多少人使用，出现等待不应该。

1、每次卡住的时候，解析日志会只显示“0 Tasks are ahead in the queue”

2、每次卡住的时候，其中一个taskexecutor的日志里，连心跳reported heartbeat都不打印了，表现为这个解析任务到这个taskexecutor后就异常停止住了一样

问题处理

1、对疑似异常的taskexecutor，打印线程堆栈，py-spy dump --p <pid> > stacktrace.txt，查看到有read bytes(pymysql/connections.py:789)的线程

怀疑与RAGFlow以来的数据库有关

2、想到新部署的环境，因为想复用已安装好的mysql，所以当前连接的mysql与RAGFlow不在一个环境，Mysql在开发环境，RAGFlow的pod部署在测试环境，这2个环境之间虽然网络可以联通

但是中间是有防火墙，tcp连接超过1200秒就会被防火墙断开，曾经部署Doris时也有类似超时的现象，于是锁定是这个原因。重新在测试环境相同网络环境部署了一套MySQL，将RAGFlow连接改到这个MySQL

3、连接新的MySQL后，不会再出现taskexecutor 心跳日志reported heartbeat不打印的情况，但是仍然间歇性出现解析任务卡住不执行的现象。

4、taskexecutor的日志里都没有打印接收解析任务的日志，怀疑是解析任务提交到redis消息队列后，而taskexecutor没有读取到redis消息队列的msg，或者可能消息队列里的这个msg被丢掉了，检查了RAGFlow

task_executor.py的collect方法，任务获取是从读取redis的msg开始，这是简单的客户端调用，代码应该不会有问题。然后连接到Redis的库上查看，发现RAGFlow在Redis上建的消息队列的名字是固定的

“rag_flow_svr_queue”，且消费组也是固定的“rag_flow_svr_task_broker”，没有按集群设置唯一名称，猜测msg被其他什么地方消费走了，问了组内一个同事才知道，他刚部署了一套自用的RAGFlow，为图方便，连了

我们的Redis，基本确定了任务的msg被他部署的RAGFlow的taskexecutor消费走了，所以才会出现我们RAGFlow解析任务间歇性的卡住问题。

5、最终停止掉同事那台自用的RAGFlow，问题解决

结论

1、RAGFlow的依赖组件，网络上不要有防火墙，尽量部署在相同环境下

2、多套RAGFlow不要共用依赖组件