[Question]: The Linux operating system based on ARM architecture parses documents too slowly

[earlBell]

Self Checks

• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report (Language Policy).
• Non-english title submitions will be closed directly ( 非英文标题的提交将会被直接关闭 ) (Language Policy).
• Please do not modify this template :) and fill in all the required fields.

Describe your problem

Why does it only take 200 - 300 seconds to process chunks of the same document on an X86 - based Ubuntu system with 4 cores and 16GB of memory, but when I move this document to a Kylin system based on the ARM architecture with 64 cores and 64GB of memory, it takes several hours or more to parse the chunks? Why is this?

[earlBell]

@dosu

[earlBell]

docker stats

CONTAINER ID   NAME             CPU %      MEM USAGE / LIMIT     MEM %     NET I/O           BLOCK I/O         PIDS 
8104c1fcc730   ragflow-server   1079.35%   10.49GiB / 62.57GiB   16.76%    990MB / 420MB     5.42GB / 23.5MB   1267 
e622c147d6e6   ragflow-minio    1.17%      527.9MiB / 62.57GiB   0.82%     219MB / 42.5MB    8.78GB / 708MB    36 
e9de37c6be69   ragflow-redis    0.18%      36.12MiB / 62.57GiB   0.06%     15.7MB / 12.6MB   37MB / 446MB      6

docker images

REPOSITORY            TAG                            IMAGE ID       CREATED         SIZE
infiniflow/ragflow    0.19-arm                       1a070134510e   8 days ago      8.47GB

PUT to es

2025-06-06 15:40:17,658 INFO     79 PUT http://192.168.32.133:1200/ragflow_5262340a35ef11f09d6462f3748bc24c/_bulk?refresh=false&timeout=60s [status:200 duration:0.033s]
2025-06-06 15:40:17,687 INFO     79 PUT http://192.168.32.133:1200/ragflow_5262340a35ef11f09d6462f3748bc24c/_bulk?refresh=false&timeout=60s [status:200 duration:0.019s] refresh=false&timeout=60s [status:200 duration:0.036s]

[dosubot]

Your ARM-based system shows extremely high CPU usage for the ragflow-server container, which matches known issues with RAGFlow's document parsing being very CPU-intensive—especially for tasks like OCR and layout analysis. RAGFlow is only officially supported on x86 CPUs and NVIDIA GPUs; while it is tested on ARM64, there are no ARM-optimized Docker images or code paths, and performance can be much worse on ARM even with more cores and memory. The code uses threading and parallelism, but these are not tuned for ARM, and some dependencies (like xgboost, OpenCV, and ONNX Runtime) may run less efficiently on ARM hardware.

To improve performance, try disabling non-essential features (like "Use RAPTOR" and "Auto-keyword"), use the "Naive" document parser if possible, and check your PARALLEL_DEVICES/thread settings to avoid excessive context switching or lock contention. The Elasticsearch PUT durations look normal and are unlikely to be the bottleneck. For ARM, building your own Docker image as per the docs is required, but even then, performance may lag behind x86 systems due to lack of architecture-specific optimizations. More details: ARM support and performance, threading and parser details, performance tuning tips.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[earlBell]

Your ARM-based system shows extremely high CPU usage for the ragflow-server container, which matches known issues with RAGFlow's document parsing being very CPU-intensive—especially for tasks like OCR and layout analysis. RAGFlow is only officially supported on x86 CPUs and NVIDIA GPUs; while it is tested on ARM64, there are no ARM-optimized Docker images or code paths, and performance can be much worse on ARM even with more cores and memory. The code uses threading and parallelism, but these are not tuned for ARM, and some dependencies (like xgboost, OpenCV, and ONNX Runtime) may run less efficiently on ARM hardware.

To improve performance, try disabling non-essential features (like "Use RAPTOR" and "Auto-keyword"), use the "Naive" document parser if possible, and check your PARALLEL_DEVICES/thread settings to avoid excessive context switching or lock contention. The Elasticsearch PUT durations look normal and are unlikely to be the bottleneck. For ARM, building your own Docker image as per the docs is required, but even then, performance may lag behind x86 systems due to lack of architecture-specific optimizations. More details: ARM support and performance, threading and parser details, performance tuning tips.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other   

Are there any other remedies? @dosu

[dosubot]

Here are a few more remedies you can try for ARM performance in RAGFlow:

• Use the "native" parsing method instead of "deepdoc" if you don't need image recognition—this is much more resource-efficient and can significantly reduce CPU/memory usage on ARM systems (source).
• Increase the memory limit for your Docker container by adjusting MEM_LIMIT in docker/.env if you see memory exhaustion or swapping (source).
• Limit the number of concurrent threads or task executors to avoid excessive context switching and lock contention, which can be worse on ARM (source).
• Disable the reranker, "Auto-keyword", "Auto-question", and "Use RAPTOR" features, as these are CPU-intensive and especially slow on non-x86 CPUs (source).
• Monitor resource usage closely and experiment with breaking large documents into smaller chunks for processing (source).
• There are no deeper ARM-specific optimizations in the core code—ARM support is handled at the Docker/dependency level, not in the main logic (source).

Official ARM64 Docker images are not planned, so custom builds and tuning are required. If you need more details on any of these steps, let me know!

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[earlBell]

Here are a few more remedies you can try for ARM performance in RAGFlow:

• Use the "native" parsing method instead of "deepdoc" if you don't need image recognition—this is much more resource-efficient and can significantly reduce CPU/memory usage on ARM systems (source).
• Increase the memory limit for your Docker container by adjusting MEM_LIMIT in docker/.env if you see memory exhaustion or swapping (source).
• Limit the number of concurrent threads or task executors to avoid excessive context switching and lock contention, which can be worse on ARM (source).
• Disable the reranker, "Auto-keyword", "Auto-question", and "Use RAPTOR" features, as these are CPU-intensive and especially slow on non-x86 CPUs (source).
• Monitor resource usage closely and experiment with breaking large documents into smaller chunks for processing (source).
• There are no deeper ARM-specific optimizations in the core code—ARM support is handled at the Docker/dependency level, not in the main logic (source).

Official ARM64 Docker images are not planned, so custom builds and tuning are required. If you need more details on any of these steps, let me know!

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other   

Why doesn't this happen with the ARM - version of ElasticSearch and MySQL?@dosu.

[earlBell]

And why is the size of the x86 version 0.19 image 15.1GB, while the ARM image is only 8.4GB (but it is indeed this size after packaging, including the embedding model)?

[dosubot]

The x86 image is larger mainly because it includes extra dependencies and components that aren't present or available in the ARM build. For example, the x86 Dockerfile installs packages like openmpi-devel, gcc-c++, miniconda, nodejs, nginx, and some Python packages, which can significantly increase the image size. Some libraries (like aspose-slides) are not available for ARM, so they're omitted from the ARM image, making it smaller. Both images include the embedding models, but the x86 build ends up with more bundled software and dependencies, which explains the size difference. You can see these architecture-specific differences in the Dockerfiles and build scripts used for each platform reference.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}