是否存在相同错误的现有问题？
- 我已检查了现有的问题。
分支名称
main
提交ID
其他环境信息
Ubuntu20
32G RAM
MEM_LIMIT = 12073741824
Server in LAN withou internet access, have downloaded openai cache file and set os.environ["TIKTOKEN_CACHE_DIR"].
Start Ragflow server with docker compose -f docker-compose-CN.yml up -d.
Using chat, embedding and vision model from other LAN server.实际行为
这个问题是可重复的。在开始批量文件解析后，几个文件解析会成功，剩余的任务会在几个小时后(开始执行RAPTOR)停滞在大约50%(没有任何错误信息出现在所有日志中)。我可以通过top命令看到python3 rag/svr/task_executor.py进程(CPU 0~0.3%)。所有的RAGFlow组件都通过docker ps正常运行。我在docker logs -f ragflow-server后可以看到以下警告信息：
/ragflow/rag/utils/es_conn.py:129: ElasticsearchWarning: A bulk action object contained multiple keys. Additional keys are currently ignored but will be rejected in a future version.
r = self.es.bulk(index=(self.idxnm if not idx_nm else当取消并重新启动停滞的文件解析时，文件解析将成功。
预期行为
所有批量文件解析都将成功。在任务停滞时在日志中显示错误信息。
重现步骤
After start bulk files parsing and then wait several hours.其他信息
- 无响应*
3条答案
按热度按时间vq8itlhq1#
RAPTOR使用llm进行摘要。因此，我认为这可能是由于本地局域网中LLM服务器的处理能力引起的。
ozxc1zmp2#
RAPTOR使用llm进行总结。因此，我认为这可能是由于本地局域网中LLM服务器的服务能力引起的。
我无法通过docker logs -f ragflow-*定位到任何相关的错误或警告日志。我建议增强日志系统，在任务状态异常时提供更详细的信息。
lndjwyie3#
RAPTOR使用llm进行摘要。因此，我认为这可能是由于本地LAN中LLM服务器的处理能力引起的。
经过广泛的调试，我最终发现，在raptor之前的文件解析任务停滞是由于REDIS_CONN.queue_product过期所致。
/ragflow/rag/settings.py
SVR_QUEUE_RETENTION = 60*60
为了解决这个问题，我建议调整/ragflow/rag/settings.py中的服务器队列保留期限。具体来说，我们应该增加SVR_QUEUE_RETENTION值，以确保队列中的项目不会过早过期。