Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Engine consumes a large amount of Memory. What methods can be used to optimize memory usage? #6168

Open
Janus-Xu opened this issue May 16, 2024 · 7 comments

Comments

@Janus-Xu
Copy link

Janus-Xu commented May 16, 2024

jina ver: 3.25.1 latest

When using an empty example to observe the idle memory usage without adding any executor, the situation is as follows:

flow.py

from jina import Flow

f = Flow()

with f:
    f.block()

In the x86 environment:

python(16985)───python(17051)─┬─{default-executo}(17054)
                              ├─{event_engine}(17058)
                              ├─{event_engine}(17059)
                              ├─{event_engine}(17060)
                              ├─{event_engine}(17061)
                              ├─{event_engine}(17077)
                              ├─{event_engine}(17080)
                              ├─{grpc_global_tim}(17056)
                              ├─{python}(17057)
                              ├─{resolver-execut}(17055)
                              └─{timer_manager}(17081)

PID 16985 occupies 80M, PID 17051 occupies 66M.

In the ARM environment:

python(3740)───python(8001)─┬─{python}(8014)
                            ├─{python}(8015)
                            ├─{python}(8016)
                            ├─{python}(8017)
                            ├─{python}(8020)
                            ├─{python}(8021)
                            ├─{python}(8022)
                            ├─{python}(8023)
                            ├─{python}(8024)
                            ├─{python}(8025)
                            └─{python}(8026)

PID 3740 occupies 308M, PID 8001 occupies 214M.

The executor is designed as multiple processes, We have also tested the memory usage of each process is around 250M-350M.
In this way, when all processes are combined in a flow, it is easy to exceed 3-4G.

There is no mention of memory in the entire documentation. Is there any solution to this problem?

@JoanFM
Copy link
Member

JoanFM commented May 16, 2024

what is the Executor you are using?

@Janus-Xu
Copy link
Author

Janus-Xu commented May 16, 2024

what is the Executor you are using?

just some business logic processing. like data format, calling external APIs, saving results to a database, etc.
and I forgot to attach flow.py. The original question has been updated. the statistics do not include the executors, only the engine itself.

@JoanFM
Copy link
Member

JoanFM commented May 16, 2024

The same Flow structure with empty executors, what consumption does it have?

@Janus-Xu
Copy link
Author

The same Flow structure with empty executors, what consumption does it have?

no consumers. We initially thought it was the executors usage problem, so we removed all the other configurations and tried to find the problem using elimination.

The ARM environment is a Nvidia Jetson box, and we also confused why there is such a difference just by changing the hardware. The box only has 16GB of memory, we originally expected it to support dozens of flows.

@JoanFM
Copy link
Member

JoanFM commented May 16, 2024

I am not sure why the memory usage is different in both? Maybe some forking differences between both architectures, or some dpeendency using more in one or the other

@Janus-Xu
Copy link
Author

I am not sure why the memory usage is different in both? Maybe some forking differences between both architectures, or some dpeendency using more in one or the other

disregarding the issue with the ARM terminal, on our standard x86 server, the total memory usage we observed during idle testing was around 150MB.
Is this memory usage consistent with the testing conducted by your team? We were hoping for a lighter footprint, ideally under 20MB.

@JoanFM
Copy link
Member

JoanFM commented May 16, 2024

yes, can be. I think most of it comes from the importing of docarray and the forking copying memory

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants